[X4U] Finder hell!

[John Daschbach]

A couple of recent experiences have refreshed my appreciation that  
the Finder is still a poorly integrated single thread program.  The  
problems seem to stem from situations that should be common to many  
Mac users.  The solutions have been painful (reset button on machines  
that still have it, pull the plug on an iMac G5) and make it clear  
that Apple has somehow failed to bring the Finder to the world of  
solid Unix programming.

My problems originate with the same underlying issue, something that  
should be handled by any reasonable program, and absolutely must be  
handled by the Finder.

At work, running the latest 10.3 on a dual G4, I started to have  
hangs in many file dialog windows "Save File As".  The spinning  
beachball would appear, and remain in force for periods of many  
hours.  The program which requested the file dialog would only offer  
the option of "Force Quit" in the dock, but dozens of Force Quits did  
nothing.  Turn to the terminal and try a standard "kill -9 pid" many  
times.  No immediate effect.  With some programs (Kaleidagraph) the  
program did eventually die after 5-15 minutes, with others (Finder,  
Safari, Entourage) I didn't see a kill over 30+ min.  Once this  
problem happens, most running programs generate spinning beachballs  
after being brought to the foreground.  Basically most every open  
program hangs!  A key in finding the problem was that an 'ls' in a  
terminal window with a dead link would hang forever.

The solution was related to the fact that our AFS servers changed IP  
addresses.  Any directory with a symlink to an AFS file system would  
hang the whole system once the AFS link was no longer valid.   
Apparently OS X has no time out on scanning a directory, so when it  
hits a dead link it waits forever for it to return a list of files.

What is surprising, and scary, is that you can't recover the system  
running as root issuing "kill -9".   In contrast to any Unix system I  
have run on OS X seems to be able to ignore kill signals.  Between 5  
and 10 times I had this happen until I diagnosed the problem, and  
each time (after 10-30 min of waiting) the only solution was a hard  
reset.

Unfortunately the same thing happened to me this today at home, when  
the computer hosting an afp mount went to sleep.  The network  
connected client computer (iMac G5) with the afp file system mounted  
exhibited the same fatal behavior, which for the iMac requires  
pulling the plug to recover.

Thus, it appear that there is a system call for scanning a directory  
that blocks kill signals and never returns if a link is dead.   
Blocking kills is something that should only be used in extreme  
circumstances, like across a fork.

Since this happens with both afs and afp mounts, and seems to be  
related to a standard system call for returning a list of files, it  
must be in the OS X core.  Such behavior is unacceptable.  I have to  
hope it will fixed at some point so that a dead file system link does  
not require power cycling a computer.

-John