Andrew Pimlott wrote:
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.
On Thu, Dec 13, 2001 at 12:23:46PM +0300, Hans Reiser wrote:
Andrew Pimlott wrote:
Are you sure that standard ftp will be able to handle extended
attributes without modification?
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.
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?
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
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
If you have permission, you can:
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