Well, it's time to put a stop to this bit of misinformation. When a file is created, it exists as soon as the create succeeds, and can be manipulated or opened again just the same as a file that's been around since 1984. Consider: open F1, ">testfile" or die "can't create testfile: $!\n"; open F2, "<testfile" or die "can't open testfile: $!\n"; This works fine. If testfile didn't exist until it was closed, it wouldn't work, the second open would fail with a "No such file or directory". There are a couple of reasons it might look like the file doesn't exist: Disk cache - Yes, disk accesses are cached, so it might be that after the file is created, it's directory entry isn't yet written to disk. However, the whole file system goes through the cache, so to an application, it looks like the file exists on disk like every other file (unless you turn off your computer without shutting down or it crashes before the directory entry gets written to disk). A system that didn't maintain the consistency of a cache would be badly broken. Finder goofiness part 1 - The Finder doesn't trap file creates (I think it should, but that's for another rant :-)), it simply examines the modification times of the directories it has open. This could mean that when a file is created, it won't appear in its proper Finder window for up to 5 seconds (and I've seen cases where the Finder doesn't notice a new file until you close and reopen the window for the folder it's in). Of course files are often open for less than 5 seconds, so this could look like the file doesn't exist until it's closed. Finder goofiness part deux - When the Finder first notices a new file, it grabs the type and creator and sets the file's Initted bit. Once a file's Initted bit has been set, the Finder doesn't grab the file's creator and type again (except for unusual circumstances, like rebuilding the desktop). So consider the following scenario: perl creates a file in response to open HANDLE, ">file" perl gives some time to other applications the Finder gets to run, notices the new file, grabs the type and creator, and sets the Initted bit perl calls SetFileInfo to change the type and creator Because the type and creator are set after the Finder has set the file's Initted bit, the Finder won't notice the change, so it will look like it didn't happen. Note that this is very timing dependent. If the Finder doesn't happen to notice the new file until after it's type and creator are set, it will see the change. That's why it may appear to work sometimes and not others. The two bits of Finder goofiness are why you should always update the modification date of a file's containing directory whenever you create a new file, and why you should always clear a file's Initted bit *after* manipulating information about the file (like creator and type, dates, etc.) Brian ***** Want to unsubscribe from this list? ***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch