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

Hans Reiser
2001-12-13T09:25:40Z

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.