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

[Hans Reiser]

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