clive@drutx.ATT.COM (Clive Steward) (09/23/88)
This just got someone back at the lab: Be in Multifinder Have folder open, with By Name line-oriented display. Create new file in folder, as by printing to PostScript file New file will have 0k indicated size! (her's was 750k, in actuality) Also leads to further confusion as printing twice gets update, so original file now has size, newest 0k again. Here's another, more minor: Have folder open, again in By Name display change name of a given file file name remains in same position in list; no re-sort of names takes place. Closing and opening folder gets around both of these. Clive Steward
barmar@think.COM (Barry Margolin) (09/27/88)
In article <8778@drutx.ATT.COM> clive@drutx.ATT.COM (Clive Steward) writes: >Be in Multifinder >Have folder open, with By Name line-oriented display. >Create new file in folder, as by printing to PostScript file >New file will have 0k indicated size! (her's was 750k, in actuality) >Also leads to further confusion as printing twice gets update, so >original file now has size, newest 0k again. Multifinder doesn't continually monitor the file system. It notices when files are created or deleted (File Manager probably sends it some kind of signal), and updates its display at those times. Continuous monitoring would probably be too much overhead. >Have folder open, again in By Name display >change name of a given file >file name remains in same position in list; no re-sort of names takes >place. I suspect this is intentional. Suppose resorting would cause the file to be outside the current window; having a file you're working with in some way suddenly disappear would be quite disconcerting. A novice might think that they had typed something that caused the file to be deleted. It's better to leave it there out of alphabetical order than to make it disappear. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
dorner@uxc.cso.uiuc.edu (Steve Dorner) (09/27/88)
In article <8778@drutx.ATT.COM> clive@drutx.ATT.COM (Clive Steward) writes: >Have folder open, again in By Name display >change name of a given file >file name remains in same position in list; no re-sort of names takes >place. This is a useful feature; otherwise, the newly renamed file would disappear somewhere, or else the window would have to be scrolled; either behavior would be disconcerting. Along the same lines, however; the Finder seems to cache information about files in open folders. This causes problems with certain programs who create files, and then give them creators and types later (or so I believe). The Finder doesn't realize that the file types have been changed until the window is closed and opened again. Double-clicking on the file before that will result in the dread ``Application not found'' alert. I really think the Finder ought to go to the disk and check before putting up that alert. An example of an application that causes this is StuffIt; try archiving your favorite document, then restoring it into an open window. You will have to close and reopen the folder before double-clicking the document. -- Steve Dorner, U of Illinois Computing Services Office Internet: dorner@garcon.cso.uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner IfUMust: (217) 244-1765
clive@drutx.ATT.COM (Clive Steward) (09/28/88)
From article <28673@think.UUCP>, by barmar@think.COM (Barry Margolin): > (0 size always on newly created files) > Multifinder doesn't continually monitor the file system. Yes, that's evident. But as Mf picks up file creations within a few seconds, surely the same signaling mechanism could be used to also inform of file close, so that size would also soon get set. This does not occur, and it does cause confusion, as in posted example. > (no re-sort on name change) > I suspect this is intentional. Suppose resorting would cause the file > to be outside the current window This is a more minor user problem. But I'd think the update from the re-sort could be centered on the interesting file, with it's new name and position? This seems costless.... N'est-ce pas? Clive
clive@drutx.ATT.COM (Clive Steward) (09/28/88)
From article <356@uxc.cso.uiuc.edu>, by dorner@uxc.cso.uiuc.edu (Steve Dorner): > Along the same lines, however; the Finder seems to cache information about > files in open folders. This causes problems with certain programs who > create files, and then give them creators and types later (or so I believe). > The Finder doesn't realize that the file types have been changed until > the window is closed and opened again. Double-clicking on the file before > that will result in the dread ``Application not found'' alert. Very good point, Steve, and I forgot about this one. As per previous message, if the Finder would update (everything) on a file close, it would fix this problem as well as the file size difficulty. In the same line we've been discussing, a delay of a few seconds wouldn't be a problem here, as with appearance following file creation. Clive
macak@lakesys.UUCP (Jim Macak) (09/28/88)
In article <8778@drutx.ATT.COM> clive@drutx.ATT.COM (Clive Steward) writes: >Here's another, more minor: >Have folder open, again in By Name display >change name of a given file >file name remains in same position in list; no re-sort of names takes >place. >Closing and opening folder gets around both of these. I agree with others that this _can_ be a useful feature. Let me add that perhaps an easier way to re-sort the names when in "By Names" display is to just go up to the menu and choose "By Names" again. Even though it is already checked, the Finder acts as if it is a new choice, and re-sorts the listing for you. Jim -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Jim --> macak@lakesys.UUCP (Jim Macak) {Standard disclaimer, nothin' fancy!} >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
nicky@cup.portal.com (09/29/88)
>Along the same lines, however; the Finder seems to cache information about >files in open folders. This causes problems with certain programs who >create files, and then give them creators and types later (or so I believe). >The Finder doesn't realize that the file types have been changed until >the window is closed and opened again. Double-clicking on the file before that >will result in the dread ``Application not found'' alert. I really think >the Finder ought to go to the disk and check before putting up that alert. > >An example of an application that causes this is StuffIt; try archiving your >favorite document, then restoring it into an open window. You will have to >close and reopen the folder before double-clicking the document. Microsoft Word seems to do this correctly. If you change a Word Document to a plain text document, the icon will change almost immediately. Any hints on how to make the finder recognize these changes? FlushVol() perhaps ? Deleting the old file and creating a new one? Nick Pilch nicky@cup.portal.com sun!cup.portal.com!nicky