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 13:30 ` Implementing POSIX ACLs - was: " Anton Altaparmakov
2001-12-11 14:34 ` Stephen C. Tweedie
2001-12-11 15:15 ` 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
[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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.