Messages in this thread | | | Date | Thu, 13 Dec 2001 23:47:01 +0300 | From | Hans Reiser <> | Subject | Re: reiser4 (was Re: [PATCH] Revised extended attributes interface) |
| |
Andrew Pimlott wrote:
>On Thu, Dec 13, 2001 at 12:23:46PM +0300, Hans Reiser wrote: > >>Andrew Pimlott wrote: >> >>>First, I write a desktop application that wants to save an HTML file >>>along with some other object that contains the name of the creating >>>application. The latter can go anywhere you want, except in the >>>same stream as the HTML file. The user has requested that the >>>filename be /home/user/foo.html , and expects to be able to FTP this >>>file to his ISP with a standard FTP program. What calls does my >>>application make to store the HTML and the application name? If the >>>answer is different depending on whether /home/user is NTFS or >>>reiserfs4, explain both ways. >>> >>Are you sure that standard ftp will be able to handle extended >>attributes without modification? >> > >No, the ftp program only needs to transfer the HTML part. > >>One approach is to create a plugin called ..archive that when read is a >>virtual file consisting of an archive of everything in the directory. >> > >Ok, does this mean that every directory in the filesystem (or in >some part of it) will automatically have a node ..archive? >Presumably, it will not appear in directory listings, but can be >read but not written to? Does this mean that a legacy application >(pathological as it may be) that expects to be able to create a file >called ..archive will fail? > I remember that I used to be a sysadmin with some NetApp boxes that have a .snapshot directory that is invisible, and has special qualities.
It worked. There were no namespace collision problems. None.
These things can be survived by users.;-)
Nothing I say should be construed to mean that I think that a particular name for a pseudo-file implemented by the default regular directory plugin is what should ship. I am easy in such matters. You can also get me to agree it should be modifiable, so that if Joe Sevenpack needs a file named ..archive, he can have it.
> > >Or do you mean that the application would explicitly create the node >associated with this plugin? > Both. If you want a file named '..glob' that does the same thing as '..archive', go for it. I am not necessarily committed to putting ..archive in the default directory plugin (actually, I don't like that name, it should be something snappier, but I haven't thought of it). I also am not funded to implement ..archive at the moment (I am funded to do inheritance though) .
> > >>It would be interesting I think to attach said plugin to standard >>directories by default along with several other standard plugins like >>..cat, etc. >> > >Anyway, you didn't answer the part I really care about. What calls >does the application make to store the HTML and the "extended >attribute"? You can pick whatever conventions you want, just give >me an example. >
read, write, etc., on file.html/..joes_attribute, unless it is a particular attribute that has particular effects on the particular plugin for file.html, in which case it all depends on the plugin and the constraints imposed on joes_attribute. It may be that modifying file.html modifies ..joes_attribute as a side-effect, plugins can do anything in response to a VFS operation. You put the plugin into your kernel, you'd better be able to trust it....
> > >>>Second, I booted NT and created a directory in the NTFS filesystem >>>called /foo . In the directory, I created a file called bar. I >>>also created a named stream called bar, and an extended attribute >>>called bar. Now I boot Linux. What calls do I make to see each of >>>the three objects called bar? >>> >>You access /foo/bar, /foo/bar/,,bar, /foo/..bar by name. >> > >How do I access the file called ..bar (created in NT) in the >directory /foo? >
If you have permission, you can: cat /foo/..bar
Or you can use the efficient for small files API we are implementing, which I won't go into here.
> > >(Anton, does NTFS define any reserved filename characters, or only >win32?) > >Andrew > >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |