> On Fri, Oct 26, 2007 at 01:10:14AM +0200, Miklos Szeredi wrote: > > > On Wed, Oct 24, 2007 at 05:27:04PM +0200, Miklos Szeredi wrote: > > > > > >> Wouldn't you be better off by attempting to implement an "open > > > > > >> by ino" operation and an operation to get the generation count > > > > > >> for the file and then modifying the network protocol of interest > > > > > >> to use these as identifiers for the file to be manipulated? > > > > > >> > > > > > > > > > > > > You mean an "open by inode" on the userspace API? My guess, it > > > > > > wouldn't get very far. > > > > > > > > > > This isn't a new idea and has been implemented on a variety of > > > > > different systems. > > > > > > > > Like? > > > > > > XFS. > > > > > > 'man open_by_handle' > > > > Doesn't seem widely used, with 600 something google hits. > > from the man page: > > "They are intended for use by a limited set of system utilities such > as backup programs." > > It also gets used by HSMs and so it is current, tested and is not > going away.... Sure. > > And in this > > old thread Linus is not entirely enthusiastic about the concept: > > > > http://lkml.org/lkml/1999/1/11/244 > > That was "open by inode number", AFAICT. A handle is an opaque > blob that can be an arbitrary length defined by the filesystem. > You have to convert a fd or path to a handle first before you can > use it later, so any filesystem can implement it... > > i.e. it is exactly what this (unanswered) post suggested: > > http://lkml.org/lkml/1999/1/13/186 Well, yeah, if a filesystem doesn't have a global index, the whole path could just be stuffed into the handle. But there's not much point in that, is there? And because the interface bypasses normal access checking on parent directories, it has security implications, making it not generally useful. Specifically, it is not useful for the "unprivileged file server" case that Peter was suggesting. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
