From: Goswin v. B. <gos...@we...> - 2010-10-20 11:19:47
|
Jean-Pierre André <jea...@wa...> writes: > Hi Goswin, > > Goswin von Brederlow wrote: >> Jean-Pierre André<jea...@wa...> writes: >> >> >>> Hi, >>> >>> Goswin von Brederlow wrote: >>> >>>>> (In general this does not matter, but when wanting >>>>> to associate a short 8+3 name to an existing long >>>>> name, I have to put it in the path the application >>>>> requested). >>>>> >>>>> >>>> Why? Where do you return any path? At most you return a filename. >>>> >>> To set a 8+3 name as a synonym to a long one, I use >>> setxattr(2) to define an attribute for the long name >>> whose value is the short name. But the short name >>> has to be inserted into the same parent directory which >>> I cannot know for sure (at least at the low level). >>> >>> Regards >>> >>> Jean-Pierre >>> >> The filename is a property of the parent directory and all calls >> concerned with the filename do get the inode of the parent directory. So >> I don't see the problem there. Surely you don't change the xattr on a >> read or write callback, only on open, create, rename, unlink, mkdir, >> rmdir. >> > > The issue happens when defining the short name, not > when using it. > > On NTFS the short name (eg "README~1.HTM") of a file > which has a long name (eg "readme_ja.html") is a kind > of hard link, but it is not a hard link. When using fuse > I cannot use the link callback, because there is no room > for an argument to discriminate from a normal hard > link. > > So I use setxattr(2) in the system name space instead : > setfattr -n system.ntfs_dosname -v README~1.HTM <path>/readme_ja.html > > The README~1.HTM has to be inserted into the parent > directory, but the fuse callback for setxattr has no > argument for parent directory. Which is where you create the problem. The name is property of the parent directory. So you should be calling the parent directory and add the name there. Something like: setfattr -n system.ntfs_dosname.README~1.HTM -v <path> readme_ja.html > Also, due to short names, even a directory may be > accessed through several paths. That I think will be a problem for the kernel. At least you might get some unexpected side effects if the permissions of the short and long name differ. > I have an approximate solution based on NTFS data, > and I could require a full path to the short name when > there is an ambiguity (so I am not asking for any new > feature). In the context of the original post, I just > wanted to point out that from a lowlevel application, > you cannot always associate a lookup() callback to a > setxattr() callback, and hence you cannot get for sure > the path the application used. True. But that is the correct behaviour. In your case say you have a file with hardlinks as dir1/file-with-long-name and dir2/file-with-long-name. Now you add a short name dir1/file~1. The dir2/file-with-long-name now has an xattr of system.ntfs_dosname=file~1 but there is no dir2/file~1. See how your approach is flawed? MfG Goswin |