Re: reiser4 (was Re: [PATCH] Revised extended attributes interface)

[Hans Reiser]

Andrew Pimlott wrote:

>On Wed, Dec 12, 2001 at 12:21:49AM +0300, Hans Reiser wrote:
>
>>Naming conventions are easy.
>>
>
>Hans,
>
>While I look forward to your work, I think Anton points out some
>issues that you really should try to address now, only you have not
>understood them.  Can I take a crack at posing some concrete
>questions that manifest the issues?
>
>Let's imagine that we have a Linux system with an NTFS filesystem
>and a reiserfs4 filesystem.  You can make any tentative assumptions
>about reiserfs4 and new API's that you like, I just want to have an
>idea of how you envision the following working:
>
>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?

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. 
 It would be interesting I think to attach said plugin to standard 
directories by default along with several other standard plugins like 
..cat, etc.

>
>
>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.

>
>
>The heart of Anton's argument is that the UNIX filesystem name space
>is basically used up--there's just not much room to add new
>semantics.  The only obvious avenue for extension is, if /foo is not
>a directory, you can give some interpretation to /foo/bar .  But
>this doesn't help if /foo is a directory.  So something has to give,
>and we want to see what will give in reiserfs4.
>
>Andrew
>
>
Naming conventions are easy, but teaching user space is hard no matter 
whose scheme is used.