On 05/ 3/10 08:23 PM, 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.
Ah, I misunderstood ... if you have the inode and a *relative* path name
(and current working directory), then yeah, you can do the walk to
canonicalize the path. That's *easy*. Its a far more constrained
problem than finding an inode (be it for a directory or a file) in the
filesystem without an initial starting point.
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"
Apparently not.
There is certainly a relationship. unlink removes the pathname to the
file, and drops the reference count. Some software creates a temp file,
and then unlinks it (while keeping the file open). This way when the
program crashes or something, the reference count is dropped to zero
"implicitly", and the file can be removed. Programs that do this are
one of the sources of "orphaned" files that sometimes get created when a
system crash happens,I think.
-- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
