On Mon, May 03, 2010 at 11:23:47PM -0400, Edward Ned Harvey wrote:
> > From: opensolaris-code-boun...@opensolaris.org [mailto:opensolaris-
> > code-boun...@opensolaris.org] On Behalf Of Garrett D'Amore
> >
> > Its worse than that -- unless the reference is in kernel memory, there
> > is no reference on disk that goes backwards from inode to path name.
>
> See what I mean, about people saying "can't be done?" ;-)
>
> As long as the object you're trying to reverse lookup happens to be a
> directory (and you happen to have the ability to open an inode by its inode
> number) then you can recursively look at the '..' entry to reverse-traverse
> the tree, until you reach the root of the tree, and at that time, you've
> been able to perform a complete reverse lookup.
>
> The same would be true for files, if the file inodes had any reference to
> their parent directory(ies). But presently, file inodes have no reference
> to their parents.
The big problem is less the lack of reference (for example, ZFS actually
keeps a (possibly stale) parent count in the znode), it's more that
since only one parent is tracked, if someone does:
ln path/to/a new/path/b
ln path/to/a new/path/c
rm path/to/a new/path/c
There's no way to get new/path/b from the inode.
> > pathname. (unlink(2) is sometimes used to leave a scratch file without
> > a name in the filesystem.)
>
> I'll have to read that manpage. Because I always thought "unlink" was the
> same as "rm"
He's referring to unlink(2), the system call, which both unlink(1m) and
rm(1) use.
Cheers,
- jonathan
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
