On 05/ 3/10 08:49 PM, Edward Ned Harvey wrote:
But so far I've had the assumption (numerously supported) that file inodes
don't currently have any reference to their parent(s). In fact, one person
on zfs-discuss (Peter Jeremy) said a file could be linked to 32767 times,
but usually it'll be a small number ... single digits ... and an inode
number is 8 bytes long. Which means you'd need flexible storage size, in
every inode, typically less than 80 bytes, but possibly up to 256kbytes
storage per file inode, to be able to reference all of its parents.
Right. And this is why *directories* can have a reference to their
parent. They always have exactly one link to them. Creating links to
directories (hard links I mean, not symlinks) is supposed to be
verboten. (This also prevents someone from creating possibly circular
structures.)
Admittedly, there is almost never a rationale reason to create two
different links *in different directories* to the same underlying
file... but the capability is there.
What I don't understand is what you think an in-kernel solution can do
which is better than a find(1) invocation.
The kernel doesn't need to know the path name to an object; as long as the
kernel knows the device and inode number of an object, it can open that
object.
Looking at the logic in the kernel, it looks like the vfs operation
"vfs_get" (see vfsops_t structure) might be the ticket here. That
function can lookup a vnode associated with a given inode number for a
given filesystem. (You have to have the vfs structure for the
filesystem itself however.)
I'm not sure if there are any convenience wrappers for the vfs_get vnode
operation. I'm also not sure that all filesystems implement this entry
point -- it appears that ufs does, but fifofs does not. (Maybe this
entry point is not interesting for all filesystems?)
Anyway, once you have the above vnode *for a directory*, then yes,
canonicalizing it (at least to the mount point of the filesystem) will
be quite easy indeed.
Handling this for files (rather than directories) will require an
exhaustive search, I'm afraid.
- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
