> From: opensolaris-code-boun...@opensolaris.org [mailto:opensolaris- > code-boun...@opensolaris.org] On Behalf Of Garrett D'Amore > > 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?)
It doesn't really matter to me, if ufs or anything else implements it. The whole reason for caring is like this: Suppose there's a directory in a ZFS filesystem, /tank/home/eharvey/foo/bar/ Suppose I want to locate all the snapshots of that directory, even if it's been renamed or moved to some other path. Then I could look up the inode number of that directory, And I would wish to open that inode (without necessarily knowing its name or absolute path) under /tank/.zfs/snapshot/snapname Then reverse-traversing the tree, to identify the complete path And if eharvey has permission to read that thing, the result is: /tank/.zfs/snapshot/snapname/home/eharvey/old/location/for/bar This reverse reference should take about the same (near-zero) time as the forward reference: ls -d /tank/.zfs/snapshot/snapname/home/eharvey/old/location/for/bar This is almost infinitely faster than performing an exhaustive tree walk, via "find -inum" vfs_get, dirtopath, zfs_obj_to_path ... I don't know. Because they all appear to be undocumented. They all take more arguments than I would have guessed, using data types that I don't recognize, and even those data types are more complex than I know what to do with. And also undocumented (that I know of.) So I'm just overwhelmed by all that. For example: zfs_obj_to_path http://src.opensolaris.org/source/search?q=&defs=&refs=zfs_obj_to_path&path= &hist=&project=/onnv is extern int zfs_obj_to_path(objset_t *osp, uint64_t obj, char *buf, int len); Well, I know what a char *buf is. And I can guess int len corresponds to the len of the buf. But I have no idea what a uint64_t is, and I have no idea what an objset_t is. I don't know how to properly construct either one of those. So I'm just looking for help, hopefully, to simplify the problem. > > 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 _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
