From: Stef B. <st...@gm...> - 2010-10-13 13:28:48
|
2010/10/13 Jean-Pierre André <jea...@wa...>: > Hi, > > Gal Rosen wrote: >> >> Hi Stef, >> >> The still something that I do not understand. >> Most of the low level interface functions are comes with fuse_ino_t, and >> some like look_up, mknod, create are comes with parent fuse_ino_t and >> name. >> Is there any syscall in libc that can extract the path from the inode, and >> also extract the path from parent inode and name ? >> Because in order to work on the file I must have the path, or maybe there >> is syscalls in libc that work on the inode ? >> > > The very problem here, is a file can have several > paths (when it is hard linked). In that situation, > which patch are you expecting ? > > To get the path, you have to keep track of the > successive lookup calls. I think this is what the > high level does. > > I am even not sure that the high level cannot > guarantee that the path sent to the driver is > the same as the one the application requested. > The fuse user-space library probably only gets > inode numbers from the kernel module and it > has to translate them to paths. Well you're right here probably. But - here comes my question - does it matter that there are more paths possible to a file?? Hardlinks are only possible to files! See my first post for an example, 3d post. That function (or procedure as you like) takes the parent entry, but the entry name before the already found path, and does so untill the root of the fs is reached. This is unique. The reason you need a path is to communicate with the backend, most likely an underlying fs in the case of an overlay fs. Now all the methods on that fs (open, stat etc) are giving the exact same result when taking differents path's! So it does not matter! Stef PS I do not know how the high level determines the path. But again does it matter really? |