[OpenAFS-devel] 1.2.8 sysname list bug

[Jack Neely]

Hi,

Wondering if anyone else has seen this behavior.  I'm working on
configuring OpenAFS 1.2.8 (the client) for use with RHL8.0 and I've
created a sysname list to deal with binary compatiblity between 8.0 and
our older 7.x binaries in AFS.  So I set the sysname to

    fs sysname ia32_redhat80 -newsys ia32_redhat8x -newsys i386_linux24

While someone else was building new binaries they found that they could
not cd into a directory sysmlink that ended in @sys (like build -> .build/@sys)
but he could cd into the symlink bin -> .install/@sys/bin.  So I did a
test case:

I created:

[slack@anduril slack]$ ls -R .hide
.hide:
i386_linux24  ia32_redhat8x

.hide/i386_linux24:
i386_linux24

.hide/ia32_redhat8x:
ia32_redhat8x

And did a:

[slack@anduril slack]$ ln -s .hide/@sys sysname

Then I tried:

[slack@anduril slack]$ ls sysname/
ia32_redhat8x
[slack@anduril slack]$ cd sysname/
[slack@anduril sysname]$ ls
ls: .: Stale NFS file handle

I did the same thing after setting the sysname to simply 'ia32_redhat8x'
and it works as you'd expect.  When I delete the ia32_redhat8x directory
I get the same stale NFS file handle but the first ls does show
i386_linux24.

I've seen this with my RHL8.0 client against an RHL7.3 server running
1.2.7 and Transarc AFS 3.6 running on solaris.

Clues?

Jack Neely

-- 
Jack Neely <slack@quackmaster.net>
Linux Realm Kit Administration and Development 
PAMS Computer Operations at NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89