From: Hans Reiser <reiser@namesys.com>
To: Andrew Pimlott <andrew@pimlott.ne.mediaone.net>
Cc: Anton Altaparmakov <aia21@cam.ac.uk>,
Nathan Scott <nathans@sgi.com>,
Andreas Gruenbacher <ag@bestbits.at>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-xfs@oss.sgi.com
Subject: Re: reiser4 (was Re: [PATCH] Revised extended attributes interface)
Date: Thu, 13 Dec 2001 23:47:01 +0300 [thread overview]
Message-ID: <3C1913C5.30701@namesys.com> (raw)
In-Reply-To: <20011205143209.C44610@wobbly.melbourne.sgi.com> <20011207202036.J2274@redhat.com> <20011208155841.A56289@wobbly.melbourne.sgi.com> <3C127551.90305@namesys.com> <20011211134213.G70201@wobbly.melbourne.sgi.com> <5.1.0.14.2.20011211184721.04adc9d0@pop.cus.cam.ac.uk> <3C1678ED.8090805@namesys.com> <20011212204333.A4017@pimlott.ne.mediaone.net> <3C1873A2.1060702@namesys.com> <20011213102729.B3812@pimlott.ne.mediaone.net>
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
>
>
next prev parent reply other threads:[~2001-12-13 20:48 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-05 3:32 [PATCH] Revised extended attributes interface Nathan Scott
2001-12-05 9:08 ` Anton Altaparmakov
2001-12-06 5:46 ` Nathan Scott
2001-12-06 3:05 ` Daniel Phillips
2001-12-06 5:41 ` Nathan Scott
2001-12-06 15:25 ` Daniel Phillips
2001-12-06 23:15 ` Nathan Scott
2001-12-07 1:45 ` Daniel Phillips
2001-12-07 2:03 ` Daniel Phillips
2001-12-07 3:51 ` Nathan Scott
2001-12-07 20:20 ` Stephen C. Tweedie
2001-12-08 4:58 ` Nathan Scott
2001-12-08 20:17 ` Hans Reiser
2001-12-11 2:42 ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Nathan Scott
2001-12-11 12:02 ` Hans Reiser
2001-12-11 19:23 ` Anton Altaparmakov
2001-12-11 20:14 ` reiser4 (was Re: [PATCH] Revised extended attributesinterface) curtis
2001-12-11 21:34 ` Hans Reiser
2001-12-11 23:04 ` curtis
2001-12-11 23:28 ` Hans Reiser
2001-12-11 23:46 ` Anton Altaparmakov
2001-12-12 1:00 ` curtis
2001-12-11 21:21 ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Hans Reiser
2001-12-11 23:33 ` Anton Altaparmakov
2001-12-11 23:59 ` Hans Reiser
2001-12-12 2:16 ` Anton Altaparmakov
2001-12-12 12:02 ` Hans Reiser
2001-12-12 13:34 ` Anton Altaparmakov
2001-12-12 15:40 ` Hans Reiser
2001-12-13 1:43 ` Andrew Pimlott
2001-12-13 9:23 ` Hans Reiser
2001-12-13 10:36 ` User-manageable sub-ids proposals Romano Giannetti
2001-12-13 13:37 ` Ragnar Kjørstad
2001-12-13 16:06 ` Romano Giannetti
2001-12-13 18:58 ` Ragnar Kjørstad
2001-12-18 0:17 ` Pavel Machek
2001-12-13 23:24 ` David Wagner
2001-12-21 21:28 ` Andreas Ferber
2001-12-13 15:27 ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Andrew Pimlott
2001-12-13 20:47 ` Hans Reiser [this message]
2001-12-13 21:01 ` Anton Altaparmakov
2001-12-10 11:52 ` [PATCH] Revised extended attributes interface Stephen C. Tweedie
2001-12-10 15:00 ` Peter J. Braam
2001-12-10 15:56 ` Stephen C. Tweedie
2001-12-10 16:00 ` Mr. James W. Laferriere
2001-12-10 16:15 ` Stephen C. Tweedie
2001-12-10 19:01 ` John Stoffel
2001-12-11 1:22 ` Timothy Shimmin
2001-12-11 11:33 ` Stephen C. Tweedie
2001-12-11 15:15 ` Implementing POSIX ACLs - was: " Anton Altaparmakov
2001-12-11 1:41 ` Nathan Scott
2001-12-11 13:47 ` Stephen C. Tweedie
2001-12-11 18:23 ` Hans Reiser
2001-12-11 18:46 ` Anton Altaparmakov
2001-12-11 23:37 ` Implementing POSIX ACLs - was " Nathan Scott
2001-12-11 13:30 ` Implementing POSIX ACLs - was: " Anton Altaparmakov
2001-12-11 14:34 ` Stephen C. Tweedie
[not found] <20011214051604.723C52B54A@marcus.pants.nu>
2001-12-14 11:10 ` reiser4 (was Re: [PATCH] Revised extended attributes interface) Hans Reiser
2001-12-14 15:06 ` dmeyer
2001-12-14 21:23 ` Bernd Eckenfels
2001-12-14 18:27 ` Brad Boyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C1913C5.30701@namesys.com \
--to=reiser@namesys.com \
--cc=ag@bestbits.at \
--cc=aia21@cam.ac.uk \
--cc=andrew@pimlott.ne.mediaone.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@oss.sgi.com \
--cc=nathans@sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).