[lkml]   [1997]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Pre-45 oopses
On Fri, 11 Jul 1997, Bill Hawes wrote:

> 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

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,


 \ /
  Last update: 2005-03-22 13:39    [W:0.038 / U:14.812 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site