[117] in Info-AFS_Redistribution
Re: problems with AFS on the NeXT
daemon@ATHENA.MIT.EDU (Wallace Colyer)
Sun May 12 17:57:55 1991
Date: Sun, 12 May 91 14:44:13 -0400 (EDT)
From: Wallace Colyer <wally+@andrew.cmu.edu>
To: erikkay@MIT.EDU, Info-AFS@transarc.com
In-Reply-To: <9105111824.AA12073@milo.mit.edu>
> 2) Some directories just lose when I try to access files within them.
> The process trying to access the file(s) goes into uninterruptible
> disk wait and hangs forever. i can access these directories from
> other platforms.
I have seen this happen mostly in the index directory. If you use
cmdebug you will seek that it is hung in some kind of write_lock.
I reported the problem to transarc and they are aparently looking into
it.
> 3) The browser hangs for a long time if i look in /afs. It takes a
> couple of minutes becuase it tries to stat every directory in the
> browser. I know this isn't really and afs problem, but has anybody
> found a solution (other than not looking at /afs) ?
What we do is change our browser to listing or icon mode. Out users'
home directories are in places with several hundred mount points it
can be real painful to ever have the browser go in there. This
behavior is much better than in version 1.0. There it would stat
every directory on the way up no matter what. Now it just stats the
visible files.
> 4) Certain programs which aren't run as the user's uid (but as root
> instead), try to access the ~/.NeXT directory, both trying to lock
> files in it, or trying to write to files within it. The only solution
> I found was to make it accessible to system:anyuser. Obviously not a
> good solution!
This is because the window server writes to the services directory.
NeXT and Transarc have been aware of this problem for a long time.
The window server is not authenticated and thus cannot write to the
directory. Aparently NeXT is close to a solution, but it is tricky.
Another problem you may not be aware of is that the Index files for
things in NeXTLibrary cannot be replicated. The NeXT Apps try to put
a lock on the index files and if they are not successfull the targets
are considered unindexed. This means you must give whoever is going
to access the files k (lock) access and cannot replicate the volumes
they live in.
-Wallace
