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/
This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:27 EST