> Michael L. Galbraith wrote:
> > This oops is new to pre-45. It didn't eat the filesystem (spare :). System is
> > up-to-the-usec tools/libs wise MMX-150-Overdrive. Oops is reproducable.
>
> I've tracked down the apparent cause of the oops in permission(). If
> the directory path includes a zombie entry, the call to permission is
> made with a null inode, generating the message you reported.
>
> I've attached a patch that tests for null and denies access, but it
> seems like we really shouldn't have paths without inodes.
>
> It's easy to reproduce the problem -- just create a directory tree, cd
> to the bottom, then delete a parent. Now try echo hi > foo and you'll
> trigger the message.
In my case, it was following a broken symlink. I moved all of my user accounts
from /home to /usr/home and (lazy) made a symlink to point to the new home.
When I prepared the test filesystem, the disk filled up before copying
/usr/home.. resulting in a broken symlink. Logging in as a user after patch..
Linux 2.1.44.
You have mail.
permission: null inode
No directory /home/mikeg!
Logging in with home = "/".
permission: null inode
permission: null inode
safedelchk: scan beginning
permission: null inode
safedelchk: removing files safedeleted before 06/12/97
permission: null inode
safedelchk: scan completed
permission: null inode
bash: /home/mikeg/.bash_profile: Permission denied
permission: null inode
permission: null inode
permission: null inode
permission: null inode
mikeg:$
mkdir -p /home/mikeg (as root) resulted in permission: null inode.. but did
create the directory tree in the correct place.
Thanks for the reply+patch,
-Mike