• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

An annoying Finder bug in MacOS 8.5+.

During my testing of Netatalk and various versions of MacOS, I came across a rather interesting bug. If the File Type for a given file is all null values (0x00), the Finder will refuse to update any of the Finder Information about the file. This includes information like the label color, icon location, etc. Looking at network traces communicating with an AFP server, the Finder never sends out FPSetFileDirInfo to update the FinderInfo. This applies to files on a hard drive as well, so not an ASC bug.

This bug appears to have emerged with the multi-threaded Finder rewrite in MacOS 8.5 (I only tested in 8.6+) and remained into MacOS 9.2.2. MacOS 8.1 and earlier do not have this problem at all. They'll merrily write FinderInfo to any file it sees.

I'm wondering how Apple's AFP server handled this, because its entirely possible that files shared off of a OS X machine will completely lack FinderInfo. I'm sure they did some generic filetype/creater mapping to avoid it (at least with AFP2.2 clients). Earlier Netatalk releases (prior to 2.0?) appear to have automatically set filetype/creator on files that lacked any FinderInfo data to TEXT/UNIX to avoid this.

There is also the possiblity that someone running OS X copies a file onto the drive without any FinderInfo and then tries to use it on classic MacOS. Surely they'll be wondering why things are acting wierd.
 
Back
Top