Re: [zfs-discuss] Reverse lookup: inode to name lookup

2010-05-05 Thread Edward Ned Harvey
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Edward Ned Harvey Thanks to Victor, here is at least proof of concept that yes, it is possible to reverse resolve, inode number --> pathname, and yes, it is almost infinitely faster than doing

Re: [zfs-discuss] Reverse lookup: inode to name lookup

2010-05-03 Thread Peter Jeremy
On 2010-May-02 01:44:51 +0800, Edward Ned Harvey wrote: >Obviously, the kernel has the facility to open an inode by number. However, >for security reasons (enforcing permissions of parent directories before the >parent directories have been identified), the ability to open an arbitrary >inode by

Re: [zfs-discuss] Reverse lookup: inode to name lookup

2010-05-02 Thread Edward Ned Harvey
> From: cas...@holland.sun.com [mailto:cas...@holland.sun.com] On Behalf > Of casper@sun.com > > It is certainly possible to create a .zfs/snapshot_byinode but it is > not > clear when it helps but it can be used for finding the earlier copy of > a > directory (netapp/.snapshot) Do you happen

Re: [zfs-discuss] Reverse lookup: inode to name lookup

2010-05-02 Thread Casper . Dik
>You can do in the kernel by calling vnodetopath(). I don't know if it >is exposed to user space. Yes, in /proc/*/path (kinda). >But that could be slow if you have large directories so you have to >think about where you would use it. The kernel caches file names; however, it cannot be use for

Re: [zfs-discuss] Reverse lookup: inode to name lookup

2010-05-01 Thread Mattias Pantzare
> If the kernel (or root) can open an arbitrary directory by inode number, > then the kernel (or root) can find the inode number of its parent by looking > at the '..' entry, which the kernel (or root) can then open, and identify > both:  the name of the child subdir whose inode number is already k

Re: [zfs-discuss] Reverse lookup: inode to name lookup

2010-05-01 Thread Edward Ned Harvey
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Mattias Pantzare > > The nfs server can find the file but not the file _name_. > > inode is all that the NFS server needs, it does not need the file name > if it has the inode number. It is n

Re: [zfs-discuss] Reverse lookup: inode to name lookup

2010-05-01 Thread Mattias Pantzare
On Sat, May 1, 2010 at 16:49, wrote: > > >>No, a NFS client will not ask the NFS server for a name by sending the >>inode or NFS-handle. There is no need for a NFS client to do that. > > The NFS clients certainly version 2 and 3 only use the "file handle"; > the file handle can be decoded by the

Re: [zfs-discuss] Reverse lookup: inode to name lookup

2010-05-01 Thread Casper . Dik
>No, a NFS client will not ask the NFS server for a name by sending the >inode or NFS-handle. There is no need for a NFS client to do that. The NFS clients certainly version 2 and 3 only use the "file handle"; the file handle can be decoded by the server. It filehandle does not contain the name

Re: [zfs-discuss] Reverse lookup: inode to name lookup

2010-05-01 Thread Mattias Pantzare
On Sat, May 1, 2010 at 16:23, wrote: > > >>I understand you cannot lookup names by inode number in general, because >>that would present a security violation.  Joe User should not be able to >>find the name of an item that's in a directory where he does not have >>permission. >> >> >> >>But, even

Re: [zfs-discuss] Reverse lookup: inode to name lookup

2010-05-01 Thread Casper . Dik
>I understand you cannot lookup names by inode number in general, because >that would present a security violation. Joe User should not be able to >find the name of an item that's in a directory where he does not have >permission. > > > >But, even if it can only be run by root, is there some wa

[zfs-discuss] Reverse lookup: inode to name lookup

2010-05-01 Thread Edward Ned Harvey
Forget about files for the moment, because directories are fundamentally easier to deal with. Let's suppose I've got the inode number of some directory in the present filesystem. [r...@filer ~]# ls -id /share/projects/foo/goo/rev1.0/working 14363 /share/projects/foo/goo/rev1.0/working/