Number: 246 Date: 22-Mar-84 10':09':15 Submitter: Sannella.PA Source: vanMelle.pa Subject: SINGLEFILEINDEX returns NIL instead of file list Assigned To: Jonl.pa Attn: Status: Closed In/By: Harmony Problem Type: Design - UI Impact: Annoying Difficulty: Frequency: Everytime Priority: Perhaps System: Other Software Subsystem: Machine: Disk: Lisp Version: Source Files: Microcode Version: Memory Size: File Server: Server Software Version: Disposition: ' ["Sannella.PA" "22-Aug-84 17':41':35" Attn': Status':(Fixed->Closed) In/By':] Description: ' Date': 21 Mar 84 12':47 PST' From': vanMelle.pa' Subject': Lisp': SINGLEFILEINDEX value returned' To': LispSupport.pa' cc': vanMelle.pa' Lisp-System-Date': 15-Mar-84 00':13':18' Machine-Type': Dorado' ' It returns NIL now, instead of a list of files to be listed, which is a tad disconcerting--looks like nothing happened.' ' -----' ' Date': 22 Mar 84 20':23 PST' From': Kaplan.pa' Subject': Lisp': SINGLEFILEINDEX bug' To': LispSupport.pa, JonL, Tong' Lisp-System-Date': 20-Mar-84 18':25':18' Machine-Type': Dorado' ' With the new SINGLEFILEINDEX loaded, if I do' (LISTFILES FOO) ' I immediately get back a value of NIL.' ' If I don''t have it loaded,' (LISTFILES FOO)' takes a while but then returns the value' ({PHYLUM}FOO.;1).' ' In other words, loading singlefileindex makes the value of LISTFILES be incorrect.' ' I don''t know if this was true in the old singlefileindex, but it is a glitch that should be fixed.' ' Also, presumably, the singlefileindex process should be responsible for removing the file from NOTLISTEDFILES when it successfully completes. It might already be doing this--don''t know.' ' -----' ' Date': 26 MAR 84 17':51 PST' From': JONL.PA' Subject': Re': Lisp': SINGLEFILEINDEX bug' To': Kaplan, LispSupport, Tong' cc': JONL' ' In response to the message sent 22 Mar 84 20':23 PST from Kaplan.pa' ' Bill had already noticed that LISTFILES was returning NIL, and I just patched SINGLEFILEINDEX to return the FULLNAME of a file *** which it is about to list ***. At least this way, it won''t return the user-supplied name for a file that doesn''t exist.' ' The minor remaining problem is that even though SINGLEFILEINDEX process is smart enough to remove the file''s ROOTFILENAME from NOTLISTEDFILES *** after it has successfully listed the file *** pooor old LISTFILES thinks it ought to be the one to do it. I''ll edit the LISTFILES in DMISC to cooperate more with the new SINGLEFILEINDEX (i.e., dont do the removal -- let SINGLEFILEINDEX process be the only one to do it), but this isn''t a real high priority bug. There should be an AR for this bug, however.' ' -----' ' Date': 26 MAR 84 17':03 PST' From': JONL.PA' Subject': Re': AR 246': SINGLEFILEINDEX returns NIL instead of file list' To': Sannella, Jonl' cc': VANMELLE' ' In response to the message sent 22 Mar 84 10':10':13 PST (Thursday) from Sannella.PA' ' Fixed (on Library>) to return the FULLNAME of the file to be' listed (reading between the lines, the bug report implies that it is' LISTFILES rather than SINGLEFILEINDEX with the "disconcerting" behaviour,' even though it said SINGLEFILEINDEX -- the latter doesn''t take a list of' files).' ' The returned value, FULLNAME of file, still is only a "hint" of file to be listed, as opposed to the former behaviour that waited until after the file was actually listed to return a value. Once can lose under this new scheme by deleting the lister process, even though LISTFILES/SINGLEFILEINDEX returned a value to its caller process.' ' Workaround: Test Case: Edit-By: Sannella.PA Edit-Date: 22-Aug-84 17':41':35