When you are running GNOME on a machine that uses AFS (the Andrew distributed FileSystem), the method in which gmc handles directores can hang the entire desktop, even gdm itself. The problem is due in part to AFS itself, and is worsened by a bug in the main AFS implementation for Linux, TransArc AFS 3.5. What happens is that when you issue an ls -l in afs root space (99% of the time it's located in /afs on the machine), the AFS client must contant each and every AFS server (cell) that is in afs space regarding permissions for the -l. Since some servers are either down, or otherwise unavailable, you end up with a terribly long wait for the ls -l to timeout. In addition, TransArc's AFS client has a bug that makes killing the ls all but impossible, AND the ls hogs AFS resources, making them unavailale to other AFS users (well, what did you expect from closed source? :) So, how does gmc come into this big mess then? Well, apparently it seems that gmc tries to determine the entire directory structure of your home directory, and to do this, it seemingly makes requests to the filesystem for permissions to see which files in the home tree are directories, thus triggering the huge wait. TransArc has been contacted about the bug in their client, but there has been no reply. Why should gmc be altered then? Well, even without the bug in the client, listings on the root afs directory tend to take a long time regardless. In addition, gmc could also create much unnessecary network traffic in the case of NFS mounted home directories..
Miguel is going to optimize some stuff that may happen to help, but there is no way the file manager features can exist without getting the information. In many ways this is purely an AFS problem, and although mc is definitely going to improve in this area, the main problem is with AFS.