Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 3731 - gmc death with AFS
Summary: gmc death with AFS
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: distribution
Version: 6.0
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Michael Fulbright
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-06-25 17:08 UTC by mikepery
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-08-03 20:32:35 UTC


Attachments (Terms of Use)

Description mikepery 1999-06-25 17:08:57 UTC
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..

Comment 1 Elliot Lee 1999-08-03 20:32:59 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.