[5290] in Release_7.7_team
Re: Minutes of 2004-08-03 release team meeting
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Aug 3 18:31:01 2005
Date: Wed, 3 Aug 2005 18:30:26 -0400
Message-Id: <200508032230.j73MUQ7F029468@egyptian-gods.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: Greg Hudson <ghudson@MIT.EDU>
CC: release-team@MIT.EDU
In-reply-to: <200508031926.j73JQsPL014726@equal-rites.mit.edu>
X-Spam-Score: 1.041
X-Spam-Level: * (1.041)
X-Spam-Flag: NO
> Garry imported a new version of AFS this week, but Andrew's testing
> indicates that it does not fix our problem.
Actually, we now think OpenAFS 1.3.86 may fix the problem Andrew's
been able to reproduce. The test case is to run "ls -l" on a
directory which you have 'l' but not 'r' access to. The lack of 'r'
access makes it imposible to stat() the files in the directory,
interfering with what ls wants to do.
Under RHEL 3, you get a bunch of "permission denied" errors for all
the files.
Under RHEL 4, you see the files listed with '?' in place of the
various bits of file information which would have been provided by the
stat() calls. This in itself is due to a change in "ls", nothing to
do with AFS. (Because this is new behavior, Andrew was confused into
thinking that it represented a bug on its own.)
With RHEL 4 and OpenAFS 1.3.83 or prior (as built for Athena), if you
then obtained tokens so that you had full access to the directory, you
would continue to be unable to access the files you had tried to
stat() earlier. With RHEL 4 and OpenAFS 1.3.86, obtaining tokens lets
you see the directory entries normally, according to Andrew's and
Garry's testing.
Our hope is that the kernel oopses seen during testing, as well as the
failures to fsck the AFS cache problem, are a direct result of
corruption resulting from whatever bug causes the inaccessible-file
bug. I'm going to divert from building 9.4-contingency and put out a
9.4.12 instead.
