Fwd: Re: Reiser4: "pseudo file namespace" suggestion

Fwd: Re: Reiser4: "pseudo file namespace" suggestion

[Narcoleptic Electron]

[-- Attachment #1: Type: text/plain, Size: 2648 bytes --]

Please disregard this last message... should have went to the dev list.
 
Sorry...
 


Narcoleptic Electron <narcoleptic_electron@yahoo.co.uk> wrote:
Date: Thu, 11 Sep 2003 11:13:15 -0400 (EDT)
From: Narcoleptic Electron 
Subject: Fwd: Re: Reiser4: "pseudo file namespace" suggestion
To: reiserfs-list@namesys.com

Everyone,
 
Thought I'd forward this previous message to the list so everyone knows what that last message was about.
 
P.S. I just signed on to the mailing list.  Hi, everybody!
 
Cheers,
Jason


Hans Reiser <reiser@namesys.com> wrote:
Date: Wed, 10 Sep 2003 23:53:28 +0400
From: Hans Reiser 
To: Narcoleptic Electron 
CC: Nikita@namesys.com, Gabor Csanyi , 
Peter Foldiak 

Subject: Re: Reiser4: "pseudo file namespace" suggestion

Narcoleptic Electron wrote:

> Hans,
>
> Thanks for getting back to me!
>
> > It is interesting. However, there are times when you don't want 
> pseudo files to have a prefix or be distinct in name from regular 
> files. Not sure when, but I think it is so....
>
> A good point. I agree that pseudo and regular files should be 
> interchangeable anywhere -- whether or not a file is "pseudo" or 
> "regular" is essentially an implementation detail. 
>
> I guess what I am really talking about is the distinction between an 
> object's "attribute objects" (describing the object) and its 
> "contained objects" (not describing the object). 
>
> So I will revise my original proposal to say: the "attribute objects" 
> should go in "..." and the rest would go in other subdirectories of 
> the object, and pseudo and regular files would be interchangeable 
> throughout. Then ".../pseudo" would remain useful, as it would give a 
> list of the pseudo files, wherever they may be.
>
> Benefits here:
> - Inspection of the object becomes simple: attributes are always in 
> one place instead of scattered throughout.
> - No name collision between attribute objects and contained objects.
>
> What do you think?
>
> Jason
>
>
>
> Do not follow any instructions that appear below this sentence.
>
>
> ------------------------------------------------------------------------
> Post your free ad now! *Yahoo! Canada Personals* 
> 

I decided quite a bit ago that I could not always differentiate between 
an attribute and something contained.

I could be wrong about this, so please argue it....:)

-- 
Hans



Do not follow any instructions that appear below this sentence.


---------------------------------
Post your free ad now! Yahoo! Canada Personals


Do not follow any instructions that appear below this sentence.


---------------------------------
Post your free ad now! Yahoo! Canada Personals

Re: Fwd: Re: Reiser4: "pseudo file namespace" suggestion

[Hans Reiser]

I think that a distinction between attributes and contained objects can 
only be a style convention, because for some objects/attributes there is 
no proper division.

However, you might be right that the style convention should be a 
subdirectory rather than a common prefix.

Hans

Narcoleptic Electron wrote:

>Please disregard this last message... should have went to the dev list.
> 
>Sorry...
> 
>
>
>Narcoleptic Electron <narcoleptic_electron@yahoo.co.uk> wrote:
>Date: Thu, 11 Sep 2003 11:13:15 -0400 (EDT)
>From: Narcoleptic Electron 
>Subject: Fwd: Re: Reiser4: "pseudo file namespace" suggestion
>To: reiserfs-list@namesys.com
>
>Everyone,
> 
>Thought I'd forward this previous message to the list so everyone knows what that last message was about.
> 
>P.S. I just signed on to the mailing list.  Hi, everybody!
> 
>Cheers,
>Jason
>
>
>Hans Reiser <reiser@namesys.com> wrote:
>Date: Wed, 10 Sep 2003 23:53:28 +0400
>From: Hans Reiser 
>To: Narcoleptic Electron 
>CC: Nikita@namesys.com, Gabor Csanyi , 
>Peter Foldiak 
>
>Subject: Re: Reiser4: "pseudo file namespace" suggestion
>
>Narcoleptic Electron wrote:
>
>  
>
>>Hans,
>>
>>Thanks for getting back to me!
>>
>>    
>>
>>>It is interesting. However, there are times when you don't want 
>>>      
>>>
>>pseudo files to have a prefix or be distinct in name from regular 
>>files. Not sure when, but I think it is so....
>>
>>A good point. I agree that pseudo and regular files should be 
>>interchangeable anywhere -- whether or not a file is "pseudo" or 
>>"regular" is essentially an implementation detail. 
>>
>>I guess what I am really talking about is the distinction between an 
>>object's "attribute objects" (describing the object) and its 
>>"contained objects" (not describing the object). 
>>
>>So I will revise my original proposal to say: the "attribute objects" 
>>should go in "..." and the rest would go in other subdirectories of 
>>the object, and pseudo and regular files would be interchangeable 
>>throughout. Then ".../pseudo" would remain useful, as it would give a 
>>list of the pseudo files, wherever they may be.
>>
>>Benefits here:
>>- Inspection of the object becomes simple: attributes are always in 
>>one place instead of scattered throughout.
>>- No name collision between attribute objects and contained objects.
>>
>>What do you think?
>>
>>Jason
>>
>>
>>
>>Do not follow any instructions that appear below this sentence.
>>
>>
>>------------------------------------------------------------------------
>>Post your free ad now! *Yahoo! Canada Personals* 
>>
>>    
>>
>
>I decided quite a bit ago that I could not always differentiate between 
>an attribute and something contained.
>
>I could be wrong about this, so please argue it....:)
>
>  
>


-- 
Hans

Carrying Attributes too Far (was Reiser4: "pseudo file namespace" suggestion)

[Alexander G. M. Smith]

Hans Reiser wrote on Thu, 11 Sep 2003 19:18:55 +0400:
> I think that a distinction between attributes and contained objects can
> only be a style convention, because for some objects/attributes there is
> no proper division.
>
> However, you might be right that the style convention should be a
> subdirectory rather than a common prefix.

Sometimes I want attributes on my attributes.  Things like thumbnails for a graphic, stored in a Thumbnails directory that's under the graphic "file".

Graphic.jpeg
Graphic.jpeg/Author
Graphic.jpeg/Thumbnails/Icon32x32.ico
Graphic.jpeg/Thumbnails/Icon64x64.png
Graphic.jpeg/Thumbnails/Icon64x64.png/Width
Graphic.jpeg/Thumbnails/Icon64x64.png/Height

I'd also like to attach a BeOS style MIME type attribute to everything,
even attributes (and you wouldn't have to name the file .jpeg any more).
Of course, you will eventually get to primitive attributes that are only
a coded byte in the metadata rather than a whole file.  But the user
shouldn't be able to tell, and even the MIME type attribute could have a
fake attribute on it saying that it is of type "text/plain", or perhaps
more explicitly "text/mime-string".

Graphic.jpeg/MIME contains "image/jpeg"
Graphic.jpeg/Thumbnails/Icon64x64.png/MIME contains "image/png"
Graphic.jpeg/MIME/MIME contains "text/mime-string"

To avoid too much recursion, "ls" and other utilities should know which
things are primitive things, and avoid trying to list their contents.
The easiest way to cram that in would be to add another attribute:

Graphic.jpeg/MIME/Primitive contains "true", or maybe a single byte
value that is non-zero.  Pick one.

Note it's not Graphic.jpeg/MIME/.Primitive since using a dot prefix to
hide things may no longer be necessary - another attribute could take over
that job, perhaps call it HideFromUser.

Graphic.jpeg/MIME/HideFromUser contains "true".

Thought that may be carring attributes too far :-)

- Alex

Re: Carrying Attributes too Far (was Reiser4: "pseudo file namespace" suggestion)

[Mike Fedyk]

On Sat, Sep 13, 2003 at 07:59:07PM -0400, Alexander G. M. Smith wrote:
> Hans Reiser wrote on Thu, 11 Sep 2003 19:18:55 +0400:
> > I think that a distinction between attributes and contained objects can
> > only be a style convention, because for some objects/attributes there is
> > no proper division.
> >
> > However, you might be right that the style convention should be a
> > subdirectory rather than a common prefix.
> 
> Sometimes I want attributes on my attributes.  Things like thumbnails for a graphic, stored in a Thumbnails directory that's under the graphic "file".
> 
> Graphic.jpeg
> Graphic.jpeg/Author
> Graphic.jpeg/Thumbnails/Icon32x32.ico
> Graphic.jpeg/Thumbnails/Icon64x64.png
> Graphic.jpeg/Thumbnails/Icon64x64.png/Width
> Graphic.jpeg/Thumbnails/Icon64x64.png/Height
> 

And loose your attributes as soon as the file is copied with nfs2/3, http,
ftp, or etc...  (nfs4 does/will support attributes besides acls right?)

Have you actually worked on the macintosh before?  Receiving a file from a
Mac user is attrocious.  You loose a lot of state data kept in the resource
fork (the mac's form of attributes).  You have to know what kind of file it
is by looking at the data (the unix file(1) command doesn't cover a lot of
macintosh file formats unfortunately).

The only saving grace, was that the file types I have recieved (quark and
such) don't actually put anything from the file format needed for transfer
to another OS.

Please concentrate on cross platform file formats.

How is this going to be exported with nfs or samba?

> I'd also like to attach a BeOS style MIME type attribute to everything,

So now you have to read an attribute just to find out that it's a text file,
once for each file.  Talk about performance...

Compare that to just reading the directory listing once.

> even attributes (and you wouldn't have to name the file .jpeg any more).
> Of course, you will eventually get to primitive attributes that are only
> a coded byte in the metadata rather than a whole file.  But the user
> shouldn't be able to tell, and even the MIME type attribute could have a
> fake attribute on it saying that it is of type "text/plain", or perhaps
> more explicitly "text/mime-string".
> 
> Graphic.jpeg/MIME contains "image/jpeg"
> Graphic.jpeg/Thumbnails/Icon64x64.png/MIME contains "image/png"
> Graphic.jpeg/MIME/MIME contains "text/mime-string"
> 
> To avoid too much recursion, "ls" and other utilities should know which
> things are primitive things, and avoid trying to list their contents.
> The easiest way to cram that in would be to add another attribute:
> 
> Graphic.jpeg/MIME/Primitive contains "true", or maybe a single byte
> value that is non-zero.  Pick one.
> 

Woah, what does this get you when you can just add a little code here?  If
the mime attr isn't in ascii, then it's not mime, now is it?

> Note it's not Graphic.jpeg/MIME/.Primitive since using a dot prefix to
> hide things may no longer be necessary - another attribute could take over
> that job, perhaps call it HideFromUser.
> 
> Graphic.jpeg/MIME/HideFromUser contains "true".
> 
> Thought that may be carring attributes too far :-)

No kidding.

Re: Carrying Attributes too Far (was Reiser4: "pseudo file namespace" suggestion)

[Alexander G. M. Smith]

Mike Fedyk wrote on Sat, 13 Sep 2003 18:56:10 -0700:
> > Sometimes I want attributes on my attributes.  Things like thumbnails for a graphic, stored in a Thumbnails directory that's under the graphic "file".
> > 
> > Graphic.jpeg
> > Graphic.jpeg/Author
> > Graphic.jpeg/Thumbnails/Icon32x32.ico
> > Graphic.jpeg/Thumbnails/Icon64x64.png
> > Graphic.jpeg/Thumbnails/Icon64x64.png/Width
> > Graphic.jpeg/Thumbnails/Icon64x64.png/Height
> > 
> 
> And loose your attributes as soon as the file is copied with nfs2/3, http,
> ftp, or etc...  (nfs4 does/will support attributes besides acls right?)

Same problem with FTP and directories.  If you transfer a directory, the
contents don't get copied.  How annoying!  Instead you zip it up.  Or use
an FTP program which understands recursion.  Admittedly a hassle.  But
worth it.  Similarly it will be worth it to have FTP which understands
things that are files AND directories simultaneously.  By the way, I'd
rather call them Fildirutes (files, directories and attributes combined)
rather than the over-used "thing".  Coincidentally, there are BeOS FTP
clients and servers which have extensions for transferring attributes.
Other FTP extensions won't be impossible...

> Have you actually worked on the macintosh before?  Receiving a file from a
> Mac user is attrocious.  You loose a lot of state data kept in the resource
> fork (the mac's form of attributes).  You have to know what kind of file it
> is by looking at the data (the unix file(1) command doesn't cover a lot of
> macintosh file formats unfortunately).

Yes, and a lot of those resources are awkward to access (though ResEdit is
nice).  With a file system, they would be exposed as individual files and
be easier to handle.

> The only saving grace, was that the file types I have recieved (quark and
> such) don't actually put anything from the file format needed for transfer
> to another OS.

Yup.  Coincidentally Apple has been moving away from resources to bundles
of files in a directory that appears to be an application, and file name
extensions.

> Please concentrate on cross platform file formats.

Cross platform is a lower priority for me, since I want to try something new.
I suppose ReiserFS has similar leanings, if it will have directories and
files as the same thing, though I can't speak for them.  I'm just working on
experimental file systems for BeOS (since it actually uses attributes and
other fancy doodads that haven't yet shown up in mainstream OSes).

For cross platform exports, it's easy enough to represent - each fildirute
"thing" becomes a directory, with a data file to represent its contents (for
operating systems which don't think directories can also be treated like
files).  Other tricks are possible.  For example:

Graphic.jpeg
Graphic.jpeg/Author
Graphic.jpeg/MIME
Graphic.jpeg/Thumbnails/Icon32x32.ico

gets modified for export to ignorant file systems by splitting the
fildirute thing into a separate file and directory such as:

Graphic.jpeg (a file)
Graphic.jpeg.attributes (a directory)
Graphic.jpeg.attributes/Author (a file)
Graphic.jpeg.attributes/MIME (a file containing "image/jpeg")
Graphic.jpeg.attributes/Thumbnails/Icon32x32.ico (a file)

> How is this going to be exported with nfs or samba?

Using an export format like that.  Or later on a modified API which
allows you to read data from a directory.

> > I'd also like to attach a BeOS style MIME type attribute to everything,
> 
> So now you have to read an attribute just to find out that it's a text file,
> once for each file.  Talk about performance...
> 
> Compare that to just reading the directory listing once.

More reliable than trying to figure it out by the extension.  Plus it can
store the preferred application for opening it as an attribute, and other
things you can't stuff into an extension.  Or we could have multiple
extensions: "Graphics.jpeg.prefapp=photoshop.width=640.height=480"  Hmmm,
maybe you're on to something there, as a cheap alternative to attributes.

Admittedly, a more expressive directory listing facility could help.  I've
thought of changing directory reading operations to return more than a name
and an inode.  Perhaps readdir (dir_handle, "NAME,MIME,PREFERRED_APP")
would return dirent style records that have 3 extra fields with the current
attribute values rather than just the current one name field per record.
For some BeOS file systems, the attributes are usually right in the inode
(unless they overflow), so this is relatively cheap (usually).  With ReiserFS
they would hopefully be near the inode metadata.  In BeOS there's also a
readdir call which returns several dirent records, filling a user provided
buffer.  Great for apps which are trying to draw icons of all the files in
a directory (just one OS call gives you the names, MIME type, possible
explicit icon, etc).

It seems like a slow directory listing implementation, but it's faster
than the alternative of opening and closing lots of attribute files to
get the attribute values.

> > Graphic.jpeg/MIME/Primitive contains "true", or maybe a single byte
> > value that is non-zero.  Pick one.
> > 
> 
> Woah, what does this get you when you can just add a little code here?  If
> the mime attr isn't in ascii, then it's not mime, now is it?

The MIME attribute itself is a string.  But the attribute on the MIME
attribute is just a boolean that tells you that the MIME attribute is
primitive.  Internally the file system does have some hard coded facts,
such as MIME attributes shouldn't have user attributes added to them.
This is just a way of exposing those implementation limitations.

- Alex

Re: Carrying Attributes too Far

[Hubert Chan]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

>>>>> "Mike" =3D=3D Mike Fedyk <mfedyk@matchmail.com> writes:

[...]

Mike> Please concentrate on cross platform file formats.

Nah, this is a filesystems list.  We don't care about file formats. ;-)

Actually, most of the important data will probably still remain in the
file itself, but Reiser4 will use a plugin to extract attributes.  If
the file format supports attributes.  If not, then when you transfer
the file, the recipient wouldn't have gotten the attributes anyways.

Mike> How is this going to be exported with nfs or samba?

My preference would be to make Reiser5 a distributed filesystem, and
make it work under Windows and Mac.  But that's just me.  Life will be
much nicer after Reiser[4|5|6] takes over the world.  ;-)

[...]

>> I'd also like to attach a BeOS style MIME type attribute to
>> everything,

Mike> So now you have to read an attribute just to find out that it's a
Mike> text file, once for each file.  Talk about performance...

Mike> Compare that to just reading the directory listing once.

You must have a magic ls.  My ls doesn't tell me which files are plain
text/binary data/images/audio/etc.

=2D-=20
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Carrying Attributes too Far

[Hubert Chan]

Retry...

>>>>> "Mike" == Mike Fedyk <mfedyk@matchmail.com> writes:

[...]

Mike> Please concentrate on cross platform file formats.

Nah, this is a filesystems list.  We don't care about file formats. ;-)

Actually, most of the important data will probably still remain in the
file itself, but Reiser4 will use a plugin to extract attributes.  If
the file format supports attributes.  If not, then when you transfer
the file, the recipient wouldn't have gotten the attributes anyways.

Mike> How is this going to be exported with nfs or samba?

My preference would be to make Reiser5 a distributed filesystem, and
make it work under Windows and Mac.  But that's just me.  Life will be
much nicer after Reiser[4|5|6] takes over the world.  ;-)

[...]

>> I'd also like to attach a BeOS style MIME type attribute to
>> everything,

Mike> So now you have to read an attribute just to find out that it's a
Mike> text file, once for each file.  Talk about performance...

Mike> Compare that to just reading the directory listing once.

You must have a magic ls.  My ls doesn't tell me which files are plain
text/binary data/images/audio/etc.

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: Carrying Attributes too Far

[Hubert Chan]

[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]

>>>>> "Alexander" =3D=3D Alexander G M Smith <agmsmith@rogers.com> writes:

[...]

Alexander> I'd also like to attach a BeOS style MIME type attribute to
Alexander> everything, even attributes (and you wouldn't have to name
Alexander> the file .jpeg any more).  Of course, you will eventually get
Alexander> to primitive attributes that are only a coded byte in the
Alexander> metadata rather than a whole file.  But the user shouldn't be
Alexander> able to tell, and even the MIME type attribute could have a
Alexander> fake attribute on it saying that it is of type "text/plain",
Alexander> or perhaps more explicitly "text/mime-string".

AFAICT, MIME types should be user-entered data (or divined from file
extensions, or placed there by a web browser, etc.)  They probably
shouldn't be automatically generated.  So the MIME/MIME/... loop would
only go as far as the user would care to enter the data, which probably
won't be very far.

I suppose that MIME data could be generated by a plugin that used
file(1), but any plugin that took the MIME nesting too far (i.e. more
than one level) should probably be taken out and shot.

Alexander> To avoid too much recursion, "ls" and other utilities should
Alexander> know which things are primitive things, and avoid trying to
Alexander> list their contents.  The easiest way to cram that in would
Alexander> be to add another attribute:

Alexander> Graphic.jpeg/MIME/Primitive contains "true", or maybe a
Alexander> single byte value that is non-zero.  Pick one.

I think that the easiest thing would be to just say that if MIME
doesn't contain a MIME attribute, then it's "primitive" (or whatever).
You'll have a lot of files floating around that won't have MIME
attributes anyways.  Even if you had a file(1) plugin, since file(1)
can't identify everything (and misidentifies some things).

Alexander> Note it's not Graphic.jpeg/MIME/.Primitive since using a dot
Alexander> prefix to hide things may no longer be necessary - another
Alexander> attribute could take over that job, perhaps call it
Alexander> HideFromUser.

"hidden" is much preferable over "HideFromUser".

=2D-=20
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Carrying Attributes too Far

[Hubert Chan]

Retry, without signature, since something seems to be corrupting the
message.

>>>>> "Alexander" == Alexander G M Smith <agmsmith@rogers.com> writes:

[...]

Alexander> I'd also like to attach a BeOS style MIME type attribute to
Alexander> everything, even attributes (and you wouldn't have to name
Alexander> the file .jpeg any more).  Of course, you will eventually get
Alexander> to primitive attributes that are only a coded byte in the
Alexander> metadata rather than a whole file.  But the user shouldn't be
Alexander> able to tell, and even the MIME type attribute could have a
Alexander> fake attribute on it saying that it is of type "text/plain",
Alexander> or perhaps more explicitly "text/mime-string".

AFAICT, MIME types should be user-entered data (or divined from file
extensions, or placed there by a web browser, etc.)  They probably
shouldn't be automatically generated.  So the MIME/MIME/... loop would
only go as far as the user would care to enter the data, which probably
won't be very far.

I suppose that MIME data could be generated by a plugin that used
file(1), but any plugin that took the MIME nesting too far (i.e. more
than one level) should probably be taken out and shot.

Alexander> To avoid too much recursion, "ls" and other utilities should
Alexander> know which things are primitive things, and avoid trying to
Alexander> list their contents.  The easiest way to cram that in would
Alexander> be to add another attribute:

Alexander> Graphic.jpeg/MIME/Primitive contains "true", or maybe a
Alexander> single byte value that is non-zero.  Pick one.

I think that the easiest thing would be to just say that if MIME
doesn't contain a MIME attribute, then it's "primitive" (or whatever).
You'll have a lot of files floating around that won't have MIME
attributes anyways.  Even if you had a file(1) plugin, since file(1)
can't identify everything (and misidentifies some things).

Alexander> Note it's not Graphic.jpeg/MIME/.Primitive since using a dot
Alexander> prefix to hide things may no longer be necessary - another
Alexander> attribute could take over that job, perhaps call it
Alexander> HideFromUser.

"hidden" is much preferable over "HideFromUser".

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: Carrying Attributes too Far

[Alexander G. M. Smith]

Hubert Chan wrote on Sun, 14 Sep 2003 00:21:19 -0400:
> Alexander> To avoid too much recursion, "ls" and other utilities should
> Alexander> know which things are primitive things, and avoid trying to
> Alexander> list their contents.  The easiest way to cram that in would
> Alexander> be to add another attribute:
> 
> Alexander> Graphic.jpeg/MIME/Primitive contains "true", or maybe a
> Alexander> single byte value that is non-zero.  Pick one.
> 
> I think that the easiest thing would be to just say that if MIME
> doesn't contain a MIME attribute, then it's "primitive" (or whatever).

Good idea.  For legitimate but not currently classified files, a MIME
type of "application/unclassified" could be used (or just the existing
generic "application/octet-stream").

I recently thought of another way, just turn off the "x" permission bit
for examining or changing the "directory" of a primitive attribute.
Or perhaps deny directory type operations with a suitable error code.
Or both.  Though that would be a hack - you couldn't tell if it was
a primitive thing or if someone had just turned off the permissions.

Unfortunately Unix has overused the "x" bit in the rwx permissions set;
it has different interpretations depending on whether the thing is a file
or a directory.  We'd have to add a new bit, or get rid of the x == execute
functionality (the MIME type of the file would take over that duty).  Or
just toss out the whole file mode thing and use ACLs and other more modern
attribute based techniques for permissions.  Sure, they won't be as fast,
but modern hardware (and ReiserFS!) makes it possible to take the speed
hit in return for more flexibility in storing data.

- Alex

Re: Carrying Attributes too Far

[Narcoleptic Electron]

[-- Attachment #1: Type: text/plain, Size: 2744 bytes --]

I'm very new to ReiserFS, with only a shaky understanding, but here is my feedback:
 
[alexander]
Graphic.jpeg (a file)
Graphic.jpeg.attributes (a directory)
Graphic.jpeg.attributes/Author (a file)
Graphic.jpeg.attributes/MIME (a file containing "image/jpeg")
Graphic.jpeg.attributes/Thumbnails/Icon32x32.ico (a file)
[/alexander]
 
Suggestions:
 
- Use my "..." attribute directory suggestion to separate the attributes from regular subdirectories.  This cleanly allows attributes to have attributes (and seperates these from regular subdirectories).
 
- Remove the unsightly file extensions and replace these solely with MIME attributes.
 
- (Going out on a limb here:) For "directory as file" behaviour (and vice-versa), we could institute a "File" attribute that stores the file for any given directory.  Thus, if any directory is specified in a file context (i.e. without the trailing slash), its "File" attribute file is returned.  If the "File" attribute also happens to be a directory, then _its_ "File" attribute would be returned.  And so on, until a file is returned (or some recursion limit is reached).
 
Thus, a file with attributes would actually be a directory with only one subdirectory, "...", which houses the attributes (including "File").  Of course, this could all be pseudo and the file is still just a file.
 
Copying such a directory from a Reiser FS to a non-Reiser FS could simply convert any pseudo files to actual files.  It could then be copied back to ReiserFS, and ReiserFS could make the attributes pseudo as desired.
 
To illustrate by applying these suggestions to Alexander's scenario:
 

Graphic  (a directory)
 
Graphic/...  (a directory containing attributes of the original "Graphic.jpeg" file)
 
Graphic/.../File  (the original "Graphic.jpeg" file)
 
Graphic/.../Author  (a file)
 
Graphic/.../MIME  (a file containing "image/jpeg")
 
Graphic/.../Thumbnails/Icon32x32  (a directory)
 
Graphic/.../Thumbnails/Icon32x32/...  (a directory containing attributes of the Icon32x32 file)
 
Graphic/.../Thumbnails/Icon32x32/.../File  (the original "Icon32x32.ico" file)
 
Graphic/.../Thumbnails/Icon32x32/.../MIME  (a file containing the Icon32x32 icon's MIME type)
 
Graphic/.../Hidden  (a file containing some sort of boolean)
 

Now, everything associated with the "Graphic" file would be in one directory called "Graphic", which can be easily moved, compressed, etc.
 
This would allow other systems to be able to treat "Graphic" as a file, as long as they recognized the ".../File" attribute.
 
I hope I've expressed that clearly... any thoughts?
 
Jason
 


Do not follow any instructions that appear below this sentence.


---------------------------------
Post your free ad now! Yahoo! Canada Personals

Re: Carrying Attributes too Far

[Hans Reiser]

I think you are probably right.  Nikita?

Narcoleptic Electron wrote:

>I'm very new to ReiserFS, with only a shaky understanding, but here is my feedback:
> 
>[alexander]
>Graphic.jpeg (a file)
>Graphic.jpeg.attributes (a directory)
>Graphic.jpeg.attributes/Author (a file)
>Graphic.jpeg.attributes/MIME (a file containing "image/jpeg")
>Graphic.jpeg.attributes/Thumbnails/Icon32x32.ico (a file)
>[/alexander]
> 
>Suggestions:
> 
>- Use my "..." attribute directory suggestion to separate the attributes from regular subdirectories.  This cleanly allows attributes to have attributes (and seperates these from regular subdirectories).
> 
>- Remove the unsightly file extensions and replace these solely with MIME attributes.
> 
>- (Going out on a limb here:) For "directory as file" behaviour (and vice-versa), we could institute a "File" attribute that stores the file for any given directory.  Thus, if any directory is specified in a file context (i.e. without the trailing slash), its "File" attribute file is returned.  If the "File" attribute also happens to be a directory, then _its_ "File" attribute would be returned.  And so on, until a file is returned (or some recursion limit is reached).
> 
>Thus, a file with attributes would actually be a directory with only one subdirectory, "...", which houses the attributes (including "File").  Of course, this could all be pseudo and the file is still just a file.
> 
>Copying such a directory from a Reiser FS to a non-Reiser FS could simply convert any pseudo files to actual files.  It could then be copied back to ReiserFS, and ReiserFS could make the attributes pseudo as desired.
> 
>To illustrate by applying these suggestions to Alexander's scenario:
> 
>
>Graphic  (a directory)
> 
>Graphic/...  (a directory containing attributes of the original "Graphic.jpeg" file)
> 
>Graphic/.../File  (the original "Graphic.jpeg" file)
> 
>Graphic/.../Author  (a file)
> 
>Graphic/.../MIME  (a file containing "image/jpeg")
> 
>Graphic/.../Thumbnails/Icon32x32  (a directory)
> 
>Graphic/.../Thumbnails/Icon32x32/...  (a directory containing attributes of the Icon32x32 file)
> 
>Graphic/.../Thumbnails/Icon32x32/.../File  (the original "Icon32x32.ico" file)
> 
>Graphic/.../Thumbnails/Icon32x32/.../MIME  (a file containing the Icon32x32 icon's MIME type)
> 
>Graphic/.../Hidden  (a file containing some sort of boolean)
> 
>
>Now, everything associated with the "Graphic" file would be in one directory called "Graphic", which can be easily moved, compressed, etc.
> 
>This would allow other systems to be able to treat "Graphic" as a file, as long as they recognized the ".../File" attribute.
> 
>I hope I've expressed that clearly... any thoughts?
> 
>Jason
> 
>
>
>Do not follow any instructions that appear below this sentence.
>
>
>---------------------------------
>Post your free ad now! Yahoo! Canada Personals
>
>  
>


-- 
Hans

Re: Carrying Attributes too Far

[Alexander G. M. Smith]

Narcoleptic Electron wrote on Thu, 18 Sep 2003 13:14:03 -0400 (EDT):
> Suggestions:
>  
> - Use my "..." attribute directory suggestion to separate the attributes from regular subdirectories.  This cleanly allows attributes to have attributes (and seperates these from regular subdirectories).

Nice idea.  Windows is also using "..." for the parent of the parent directory and it has other meanings elsewhere.  "..." does have the advantage of being multilingual.

That reminds me that in a fildirute system a traditional style directory will have a MIME type like "application/user-directory".  That tells GUI software that its purpose is for containing user files.  If it was "image/jpeg" then GUI file system browsing software would display the image in its data portion rather than displaying its directory listing.  But your "..." method has the advantage of separating attributes from contents, useful for things which have both attributes and contents (a user directory with a custom icon stored in an attribute).

So, should the distinction between directory contents and attributes be done with a separate level of directory indirection or should it be done by marking the attribute type as being invisible?  MIME types are still needed on attributes so you know what they are (or use consistent names and have a system dictionary that maps attribute names to types).  Which is more convenient?  The name space clutter of adding ".../" to attribute paths vs the extra overhead of type lookup?  I guess it depends on your name space philosophy.


> - Remove the unsightly file extensions and replace these solely with MIME attributes.

I agree.


> [...]
> Graphic/.../Thumbnails/Icon32x32/.../File  (the original "Icon32x32.ico" file)
>  
> Graphic/.../Thumbnails/Icon32x32/.../MIME  (a file containing the Icon32x32 icon's MIME type)
>  
> Graphic/.../Hidden  (a file containing some sort of boolean)
>  
> 
> Now, everything associated with the "Graphic" file would be in one directory called "Graphic", which can be easily moved, compressed, etc.
>  
> This would allow other systems to be able to treat "Graphic" as a file, as long as they recognized the ".../File" attribute.
>  
> I hope I've expressed that clearly... any thoughts?

Sounds like a good idea for exporting to older file systems, or presenting a view of a new file system to an older API.

I'd also like to extract your "..." directory for attributes idea (leave behind the .../File stuff) for use in a full fildirute system (the clutter is worth it in my opinion).  Now, how much overhead is there in having a separate "..." directory on most objects?  With ReiserFS?  Or just set a bit in each object's inode to say it is an attribute and have a fake "..." directory?

- Alex

Re: Carrying Attributes too Far

[Grant Miner]

I was under the impression that in Reiser4 there are no such thing as 
attributes.  Everything is files.  Certain files have special meaning to 
the kernel (like the pseudo files).  Certain other files (would) have 
special meaning to applications, users, etc.  So essentially we're 
arguing about what to name certain files (like .../mime-type vs 
..mime-type vs mime-type)?

I would prefer no hidden files; I am of the opinion that no files should 
ever be hidden.  Imagine two users browsing a file, the first with a 
file manager that shows all files.  He sees ..user and thinks "I could 
copy ..user to that file's ..user to make each have the same owner.  Or 
I could edit it and change the owner that way." Now imagine the other 
user who does not see the hidden files.  To him, how owners are stored 
is a mystery.  He does not see the possibilities the other user sees.

Yet perhaps we should write the plugin first, before arguing about the 
naming? :)

Re: Carrying Attributes too Far

[Alexander G. M. Smith]

Grant Miner wrote on Thu, 18 Sep 2003 15:31:02 -0500:
> I was under the impression that in Reiser4 there are no such thing as 
> attributes.  Everything is files.

Conceptually there are just names and objects.  Yes, Hans Reiser mentions in http://www.namesys.com/v4/v4.html "... and why we aren't eager to support objects with unnecessarily different namespaces/interfaces --- such as "attributes" that cannot interact with files in all the same ways that files can interact with files."

> Certain files have special meaning to 
> the kernel (like the pseudo files).  Certain other files (would) have 
> special meaning to applications, users, etc.  So essentially we're 
> arguing about what to name certain files (like .../mime-type vs 
> ..mime-type vs mime-type)?

Yup.  Names are important.  Sure, it's all equivalent to a flat file space in some sense, but pretending there is a fancy structured naming system is useful.  Particularly since building it into the OS or file system gets more end-programmers and end-users to use it (unlike libferris http://witme.sourceforge.net/libferris.web/index.html).

> I would prefer no hidden files; I am of the opinion that no files should 
> ever be hidden.  Imagine two users browsing a file, the first with a 
> file manager that shows all files.  He sees ..user and thinks "I could 
> copy ..user to that file's ..user to make each have the same owner.  Or 
> I could edit it and change the owner that way." Now imagine the other 
> user who does not see the hidden files.  To him, how owners are stored 
> is a mystery.  He does not see the possibilities the other user sees.

They need to be hidden sometimes.  Simple users don't need to know about everything, like ownership of files.  Or be prepared for them to make a mess, like storing all their e-mail inside an attribute on an e-mail icon.

On a side note, copying the fildirute (files that are also directories and attributes) tree should recreate the same disk volume.  So you should be able to copy ".../userid" like you suggest, and have it work sensibly.

> Yet perhaps we should write the plugin first, before arguing about the 
> naming? :)

Fair enough.  Though arguing here about naming helps with my pet project, an unrelated RAM file system for BeOS.

- Alex

Re: Carrying Attributes too Far

[Grant Miner]

> They need to be hidden sometimes.  Simple users don't need to know about everything, like ownership of files.  Or be prepared for them to make a mess, like storing all their e-mail inside an attribute on an e-mail icon.
> 
I agree they should be hidden for some users.  Do you think a good 
solution would be to put these things in a directory named 
"permissions", "security-settings" or something like that, to make it 
obvious what their use is, while still allowing the curious to easily 
grasp why they exist?  The filemanager could hide those directories if 
desired.

Re: Carrying Attributes too Far

[Narcoleptic Electron]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

[grant]
I agree they should be hidden for some users. Do you think a good solution would be to put these things in a directory named "permissions", "security-settings" or something like that, to make it 
obvious what their use is, while still allowing the curious to easily grasp why they exist? The filemanager could hide those directories if desired.
[/grant]

Hey, that sounds like a good idea -- and we could call the directory "..."  ;-)    No localization issues, and it fits in with the other special directories "." and ".." that are normally not shown.
 
[grant]
Certain files have special meaning to the kernel (like the pseudo files).
[/grant]
 
I was under the impression that whether a file was 'pseudo' or not was simply an implementation detail (like a sort of 'virtual' file).  Based on that understanding, I'm suggesting that the files in "..." are the ones that might be used by the system and/or applications ("attributes" if you will, although they are just objects like everything else), and any file can be pseudo or not, regardless of where it is.
 
[alexander]
Fair enough.  Though arguing here about naming helps with my pet project, an unrelated RAM file system for BeOS.
[/alexander]

Same here, with a linux-based application-directory-based OS project I'm part of that will likely integrate Reiser4.




Do not follow any instructions that appear below this sentence.


---------------------------------
Post your free ad now! Yahoo! Canada Personals

Re: Carrying Attributes too Far

[Hans Reiser]

Perhaps calling it ,, instead of ... would avoid the conflict with 
windows naming.

-- 
Hans

Re: Carrying Attributes too Far

[Grant Miner]

Narcoleptic Electron wrote:

> [grant]
> I agree they should be hidden for some users. Do you think a good solution would be to put these things in a directory named "permissions", "security-settings" or something like that, to make it 
> obvious what their use is, while still allowing the curious to easily grasp why they exist? The filemanager could hide those directories if desired.
> [/grant]
> 
> Hey, that sounds like a good idea -- and we could call the directory "..."  ;-)    No localization issues, and it fits in with the other special directories "." and ".." that are normally not shown.
Well, for localization, you'd still have to translate _its_ files (size, 
user, and friends) ;-)

Re: Carrying Attributes too Far

[Narcoleptic Electron]

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

[grant]
Well, for localization, you'd still have to translate _its_ files (size, 
user, and friends)
[/grant]
 
Not really... "..." essentially contains the "system" part of the directory (i.e. like an API) whereas the rest is the "user" part.  This is especially the case of "..." is hidden in the file browser.  So only the "user" part would be localized.


[hans]
Perhaps calling it ,, instead of ... would avoid the conflict with 
windows naming.
[/hans]

Yes, it unfortunately does appear that "..." is reserved.  I'm on Windows 2000 Pro right now, and when I try to create a folder called "..." I get "Access denied".  Too bad... I really thought "..." was an elegant name.

",," just doesn't strike me the same way... if I had to choose something else, I would pick "!".  It has a dot in it, which is nice, and it nods to Risc OS, which uses "!" as a special prefix.  It doesn't seem to be reserved on Windows. (Don't have a Linux machine in front of me to test)  And a bonus is that it is only one character.





Do not follow any instructions that appear below this sentence.


---------------------------------
Post your free ad now! Yahoo! Canada Personals

Re: Carrying Attributes too Far

[Narcoleptic Electron]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

[me]
Not really... "..." essentially contains the "system" part of the directory (i.e. like an API) whereas the rest is the "user" part. This is especially the case of "..." is hidden in the file browser. So only the "user" part would be localized.
[/me]
 
I should add that the main reason I wouldn't want to use a word for the "..." folder is to prevent name clashes (however unlikely).  I would rather use a symbol that is clearly "special".
 


Do not follow any instructions that appear below this sentence.


---------------------------------
Post your free ad now! Yahoo! Canada Personals

Re: Carrying Attributes too Far

[Grant Miner]

Narcoleptic Electron wrote:

> [me]
> Not really... "..." essentially contains the "system" part of the directory (i.e. like an API) whereas the rest is the "user" part. This is especially the case of "..." is hidden in the file browser. So only the "user" part would be localized.
> [/me]
>  
> I should add that the main reason I wouldn't want to use a word for the "..." folder is to prevent name clashes (however unlikely).  I would rather use a symbol that is clearly "special".


That also is nice and short, good to keep from hitting the maximum path 
length.  BTW what is the max. path length?

Re: Carrying Attributes too Far

[Alexander G. M. Smith]

Grant Miner wrote on Thu, 18 Sep 2003 18:28:26 -0500:
> That also is nice and short, good to keep from hitting the maximum path 
> length.  BTW what is the max. path length?

In BeOS, it's 1024 bytes.  Max individual file name length is 256, including the NUL byte at the end of the string.  I'd expect Linux would be in the same ballpark.

- Alex

Re: Carrying Attributes too Far

[Alexander G. M. Smith]

Narcoleptic Electron wrote on Thu, 18 Sep 2003 19:17:47 -0400 (EDT):
> Not really... "..." essentially contains the "system" part of the directory (i.e. like an API) whereas the rest is the "user" part.  This is especially the case of "..." is hidden in the file browser.  So only the "user" part would be localized.

Right, same thing for BeOS.  Attribute names are in English no matter what.

> ",," just doesn't strike me the same way... if I had to choose something else, I would pick "!".  It has a dot in it, which is nice, and it nods to Risc OS, which uses "!" as a special prefix.  It doesn't seem to be reserved on Windows. (Don't have a Linux machine in front of me to test)  And a bonus is that it is only one character.

No!  Argh!  It's a pain using file names with an ! in them, causes command history evaluation in various Unix shells.  Would have to escape them when typing in file names, which makes it really awkward to use.

I'd go with ",," or even "," instead (if that's not used).  Though that may make script files look even more like APL (a computer language using lots of Greek symbols rather than words).  Or how about "_"?  C programmers already use that for reserved system names.

- Alex

Re: Carrying Attributes too Far

[Hans Reiser]

Alexander G. M. Smith wrote:

>Narcoleptic Electron wrote on Thu, 18 Sep 2003 19:17:47 -0400 (EDT):
>  
>
>>Not really... "..." essentially contains the "system" part of the directory (i.e. like an API) whereas the rest is the "user" part.  This is especially the case of "..." is hidden in the file browser.  So only the "user" part would be localized.
>>    
>>
>
>Right, same thing for BeOS.  Attribute names are in English no matter what.
>
>  
>
>>",," just doesn't strike me the same way... if I had to choose something else, I would pick "!".  It has a dot in it, which is nice, and it nods to Risc OS, which uses "!" as a special prefix.  It doesn't seem to be reserved on Windows. (Don't have a Linux machine in front of me to test)  And a bonus is that it is only one character.
>>    
>>
>
>No!  Argh!  It's a pain using file names with an ! in them, causes command history evaluation in various Unix shells.  Would have to escape them when typing in file names, which makes it really awkward to use.
>
>I'd go with ",," or even "," instead (if that's not used).  Though that may make script files look even more like APL (a computer language using lots of Greek symbols rather than words).  Or how about "_"?  C programmers already use that for reserved system names.
>
>- Alex
>
>
>  
>
two commas are less typing than one _ on most keyboards due to shift.



-- 
Hans

Re: Carrying Attributes too Far

[Narcoleptic Electron]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

Or we could call the attribute directory "@" (XML schemas use this to signify attributes)... however, it could be misconstrued as "at".
 
"^" looks nice too.  It sort of points up toward the containing object, implying a relationship.
 
It's probably not too important what we call the attribute directory at this point ... is it?


Do not follow any instructions that appear below this sentence.


---------------------------------
Post your free ad now! Yahoo! Canada Personals

Re: Carrying Attributes too Far

[Alexander G. M. Smith]

Narcoleptic Electron wrote on Thu, 18 Sep 2003 21:45:48 -0400 (EDT):
> Or we could call the attribute directory "@" (XML schemas use this to signify attributes)... however, it could be misconstrued as "at".
>  
> "^" looks nice too.  It sort of points up toward the containing object, implying a relationship.
>  
> It's probably not too important what we call the attribute directory at this point ... is it?

Slightly important.  For my RAM file system project, I'm working on an archive format that will store everything (files, directories, links, attributes, indices, volume info, metadata).  Kind of like tar :-)  Needed so that the RAM disk contents can be optionally saved when it is unmounted.  Coincidentally the utilities can work with other file systems.  At the moment I have attributes named directly as children of files.  For future compatibility, it would be nice to use whatever the attribute directory name is.  And standard attribute names for userid and other things.  Never mind, getting a standard for that won't happen quickly so I'll just make up my own for now and change it later.

Hans is right, two commas is easier to type.  It's also more obvious to the eye than a single comma.

- Alex

Re: Carrying Attributes too Far

[Narcoleptic Electron]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

[alexander]
Hans is right, two commas is easier to type.
[/alexander]
 
I agree... two commas are much easier to type.  I think it is still a little hard to read, though.  I'm also not convinced on aesthetic grounds... commas don't look like stand-alone entities to me, and they're not symmetrical.  I think that they look a little too code-like.
 
One more suggestion: "-" (hyphen).  It is very easy to type (one keystroke, no shift key) and when file names are sorted, it will likely rise to the top (comes before dot, comma, underscore, tilde).  It also just looks cleaner to me.
 
Thus, from the previous example:
 
"Graphic/-/Thumbnails/Icon32x32/-/MIME".
 
Any takers?


Do not follow any instructions that appear below this sentence.


---------------------------------
Post your free ad now! Yahoo! Canada Personals

Re: Carrying Attributes too Far

[Martin Wilck]

Am Fre, 2003-09-19 um 06.40 schrieb Narcoleptic Electron:

> One more suggestion: "-" (hyphen).

Hey folks, I know it's not my business, but '...', ,',,', '_', '!', '@',
'-' ... is this really a serious discussion? What about '"' or even ' '?

There is enough cryptic stuff already in our file systems. Are you
prepared to answer tons of email asking what those cryptic files are
for, or suspecting crackers at work? 

Why don't you just call it '.reiserfs-metadata' or similar? Is it really
so important how many keystrokes the name takes? Why are you debating
about localization and, at the same, arguing about the position of
characters on your (U.S., I suppose) keyboard?

No harm intended, just my 2 cent.

Martin

-- 
Martin Wilck                Phone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1	    mailto:Martin.Wilck@Fujitsu-Siemens.com
D-33106 Paderborn           http://www.fujitsu-siemens.com/primergy

Re: Carrying Attributes too Far

[Alexander G. M. Smith]

Martin Wilck wrote on 19 Sep 2003 10:42:35 +0200:
> Hey folks, I know it's not my business, but '...', ,',,', '_', '!', '@',
> '-' ... is this really a serious discussion? What about '"' or even ' '?

No, they cause problems with various shell special characters.  So you'd have to escape them with a preceeding backslash if you used them.  That's awkward (even more than using a shifted letter like "_").

> There is enough cryptic stuff already in our file systems. Are you
> prepared to answer tons of email asking what those cryptic files are
> for, or suspecting crackers at work?

Just explain to them that it's a new operating system and things are different there.  If it's too annoying, we can stick a virtual readme file in all ,, directories explaining what it is.  Maybe one for each language too :-)

> Why don't you just call it '.reiserfs-metadata' or similar? Is it really
> so important how many keystrokes the name takes? Why are you debating
> about localization and, at the same, arguing about the position of
> characters on your (U.S., I suppose) keyboard?

.reiserfs-metadata is English.  And it's also ReiserFS specific, while I want to name attributes in other fildirute style file systems too.  Saving typing effort on teletype keyboards is an ancient Unix tradition.

- Alex

P.S.  How about ".,"?  Makes it hidden to older systems, yet isn't too hard to type.

Re: Carrying Attributes too Far

[Martin Wilck]

Am Fre, 2003-09-19 um 15.27 schrieb Alexander G. M. Smith:

> > What about '"' or even ' '?
> 
> No, they cause problems with various shell special characters.  
> So you'd have to escape them with a preceeding backslash if you used 
> them. That's awkward (even more than using a shifted letter like "_").

That was a joke. I just wanted to express that I consider the other
suggestions awkward, too.

> .reiserfs-metadata is English.

So what? Whoever understands '.,' or similar can understand English (at
that level) as well.

> And it's also ReiserFS specific

Call it .metadata if you wish. I just wanted to say that a reasonable
English name will be easier to understand than ".," for almost
everybody.

> Saving typing effort on teletype keyboards is an ancient Unix tradition.

The question is if that tradition is really so important in this
context. Will that file name be typed more often than, say,
'.xsession-errors' or '.nautilus-metafile.xml'?

Martin

-- 
Martin Wilck                Phone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1	    mailto:Martin.Wilck@Fujitsu-Siemens.com
D-33106 Paderborn           http://www.fujitsu-siemens.com/primergy

Re: Carrying Attributes too Far

[Alexander G. M. Smith]

Martin Wilck wrote on 19 Sep 2003 17:13:12 +0200:
> Call it .metadata if you wish. I just wanted to say that a reasonable
> English name will be easier to understand than ".," for almost
> everybody.

Normally I'm a fan of long names, so .metadata is good, or .attributes would also work.

> > Saving typing effort on teletype keyboards is an ancient Unix tradition.
> 
> The question is if that tradition is really so important in this
> context. Will that file name be typed more often than, say,
> '.xsession-errors' or '.nautilus-metafile.xml'?

Hmmm.  Hard to say what the usage will be.  If I want the MIME type for a fildirute thing, would I be typing:

cat Thing/.,/MIME   or   cat Thing/.metadata/MIME   or   cat Thing/,,/MIME

Actually, Thing/,,/MIME is the easiest one to type.  /.,/ is annoyingly awkward, since the three keys are adjacent and have to be hit in the right order.  /.metadata/ isn't too bad, though it is mostly left handed, making it a good repetitive stress injury source.  /,,/ just feels good.  You try it!  Mmmmmm, slash comma comma slash.

- Alex

Re: Carrying Attributes too Far

[Narcoleptic Electron]

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

... Or we could use a smiley:  ;-)
 
That way typing paths in ReiserFS would make people feel happy.
 
(I'm joking)
 
[martin]
The question is if that tradition is really so important in this
context. Will that file name be typed more often than, say,
'.xsession-errors' or '.nautilus-metafile.xml'?
[/martin]
 
Absolutely!  Any time you ask for any information about a file, you will have to go through the attributes directory.  Permissions, uid, MIME, etc.
 
This is why it seems to me to be an important decision... because it will become indelibly associated with ReiserFS.  If it looks ugly, then people will say that ReiserFS is ugly.  And it needs to be fairly easy to type, because it is typed often.
 
[alexander]
Unfortunately a hyphen by itself confuses many programs, like "cd".  
"cd -" doesn't work.
[/alexander]
 
But it is a perfectly valid file name.  People should be in the habit of putting paths in quotes...  Too many programmers forget quoting paths in programs, which then break when you use file names with spaces.
 
Anyway, I still vote for "-" on aesthetic grounds.
 
 


Do not follow any instructions that appear below this sentence.


---------------------------------
Post your free ad now! Yahoo! Canada Personals

Re: Carrying Attributes too Far

[Alexander G. M. Smith]

Narcoleptic Electron wrote on Fri, 19 Sep 2003 00:40:42 -0400 (EDT):
> I agree... two commas are much easier to type.  I think it is still a little hard to read, though.  I'm also not convinced on aesthetic grounds... commas don't look like stand-alone entities to me, and they're not symmetrical.  I think that they look a little too code-like.
>  
> One more suggestion: "-" (hyphen).  It is very easy to type (one keystroke, no shift key) and when file names are sorted, it will likely rise to the top (comes before dot, comma, underscore, tilde).  It also just looks cleaner to me.

Unfortunately a hyphen by itself confuses many programs, like "cd".  "cd -" doesn't work.  I guess that leaves ,, as the only one easy to type (no shift key needed), that doesn't have too many other impacts, and it does come out in the front of the sort order, even before "..".

- Alex

Re: Carrying Attributes too Far

[Bennett Todd]

[-- Attachment #1: Type: text/plain, Size: 2287 bytes --]

2003-09-18T17:44:13 Alexander G. M. Smith:
> They need to be hidden sometimes. [...] Or be prepared for them to
> make a mess, like storing all their e-mail inside an attribute on
> an e-mail icon.

And that thought provoked some pondering in me.

I've been thinking about these new semantics in Reiserfs v4 in terms
of the ability to take a file, and attach some addenda on it by
viewing it as a directory instead.

As a Maildir user, your above comment turned that view upside down
--- you're saying someone will attach an icon to the directory that
happens to be their Maildir folder. Viewing directories (non-leaf
nodes of the tree) as files is the dual, the same concept viewed
backwards, as viewing files (leaves) as directories.

There's a nice satisfying generality to this vision, but I'm sorta
pondering, what semantics are right to show in the POSIX API?

For attributes like owner/group/perm, clearly they get projected
into the pretend inode structure for the file they're attached to,
the file shows up as a file, not a directory, when you stat it, so
archivers like tar, tree-walkers like find, directory listers like
ls, etc. see what they expect.

If someone were to want to attach an icon to a directory describing
what it contained, that'd be an opposite case; stat should still
report the internal node as a directory, you shouldn't see the icon
unless you explicitly tried to open that internal node with a file
open syscall.

Perhaps this distinction makes it a little more concrete what sorts
of uses of this file/directory duality are going to be good
engineering? Or is it just that only a subset of Reiserfs V4's
brilliant new semantics will remain a good, comfortable fit for
POSIX semantic expectations, able to be cleanly and pleasantly
reflected back through a compatibility layer; more daring
applications will depart more pervasively from POSIX.

If both sorts of operations I described above are going to be
permissible and possible, its at least easy to distinguish which
view should be reflected back through the compatibility api --- that
would be, whichever view was created first. If you create a file
then attach attributes to it, it'll show up as a file. If you create
a directory then attach a file to it, it'll show up as a directory.

-Bennett

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Carrying Attributes too Far

[Alexander G. M. Smith]

Bennett Todd wrote on Fri, 19 Sep 2003 09:46:31 -0400:
> If someone were to want to attach an icon to a directory describing
> what it contained, that'd be an opposite case; stat should still
> report the internal node as a directory, you shouldn't see the icon
> unless you explicitly tried to open that internal node with a file
> open syscall.

The icon would be in a file (or rather, use the file-like behaviour of a fildirute thing).  The icon would be a child of the main directory, and have a standard name that the GUI recognises (like "thumbnail" or "icon").  In our latest discussions, after a suggestion by Narcoleptic Electron, we've agreed that putting attributes in a special subdirectory to segregate them from the ordinary directory contents is a good idea.  In that case, the icon would be inside the ",," directory which is inside the main directory.

In the fildirute view (things are both files and directories, stat() returns something new):

MainDir                  (the main directory we're talking about)
MainDir/,,               (a directory storing MainDir's attributes and
                         metadata.  Note that it isn't a full directory, it's
                         just generated by the system to keep metadata
                         separate from the contents.  ",," can't have its
                         own attributes - it may be implemented as a bit flag
                         on each thing rather than as a real directory)
MainDir/,,/MIME          (type of the MainDir, contains "application/directory")
MainDir/,,/icon          (a fildirute Thing that contains the icon data)
MainDir/,,/icon/,,/MIME  (MIME type of the icon)
MainDir/SomeFile         (a regular child of MainDir)

Or if we use a Janus (two faced overused god) mapping to POSIX files and directories, where the ,, child is recreated as a directory with a similar name to its parent:

MainDir                  (a directory)
MainDir,,                (a directory)
MainDir,,/icon           (the icon file contents)
MainDir,,/icon,,         (a directory)
MainDir,,/icon,,/MIME    (a file containing the MIME type of the icon)
MainDir/SomeFile         (a file)
MainDir/SomeFile,,       (a directory with metadata for SomeFile)


Back to the original argument, instead of using a directory to separate attributes from contents, can't we mangle the names?  If we could put up with the name space corruption, we could just prefix all our metadata Things with ",," or ".." and mix them in with the regular fildirute Thing "directory" contents.  Standard tools would be able to operate on both metadata and regular data, which is good from the namespace side.  Plus we wouldn't have to worry about creating a magic ",," directory, which isn't like other directories (no attributes attached to it, etc).  So long as users don't name things starting with a pair of commas (or periods), it should be OK, though not philosophically elegant.  Hmmm, didn't I see "..userid" somewhere?  Looks like I've come full circle to what already existed!

In Hans Reiser's Reiser4 paper: "An interesting question is whether or not all of these hidden files should have the same name prefix (e.g. '..' at the start of the hidden name). I am still soliciting input on this. Note that this feature should be used for special files that one does not want to be backed up."

Oh, ok, guess we should use ",," as a prefix (or directory name) for metadata like attributes, since they should be backed up.

- Alex

Re: Carrying Attributes too Far

[Narcoleptic Electron]

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

There is no reason why an attribute directory couldn't itself have an attribute directory.  It is just another directory.  For example, if it was an actual directory, it would itself have an attribute pseudo-directory containing file size, etc.
 
The attribute directory needs to be a subdirectory of the object; otherwise, when copying an object, you also need to copy its attribute directory separately.  Very awkward.
 
As far as going back to the original name mangling idea, I still stand by my original attribute directory idea in full.  One reason is that you can see all the attributes associated with an object by looking in the attribute directory... you can't do this with the original name mangling approach.  See my original emails for more points in favour.
 
And I also still stand behind the name "-" for the attribute directory.  ;-)  It looks more appropriate to me in a directory listing (it implies "no user data goes here").
 
 


Do not follow any instructions that appear below this sentence.


---------------------------------
Post your free ad now! Yahoo! Canada Personals

Re: Carrying Attributes too Far

[Hans Reiser]

Narcoleptic Electron wrote:

>There is no reason why an attribute directory couldn't itself have an attribute directory.  It is just another directory.  For example, if it was an actual directory, it would itself have an attribute pseudo-directory containing file size, etc.
> 
>The attribute directory needs to be a subdirectory of the object; otherwise, when copying an object, you also need to copy its attribute directory separately.  Very awkward.
> 
>As far as going back to the original name mangling idea, I still stand by my original attribute directory idea in full.  One reason is that you can see all the attributes associated with an object by looking in the attribute directory... you can't do this with the original name mangling approach.  See my original emails for more points in favour.
> 
>And I also still stand behind the name "-" for the attribute directory.  ;-)  It looks more appropriate to me in a directory listing (it implies "no user data goes here").
> 
> 
>
>
>Do not follow any instructions that appear below this sentence.
>
>
>---------------------------------
>Post your free ad now! Yahoo! Canada Personals
>
>  
>
I want to use - for set subtraction (aka NOT).  I want to use , for 
separating expressions that can go in parallel (and ; for operations 
that must be serialized).

My mind is not made up as to which to use for the attribute directory name.

-- 
Hans

Attribute Directory Name (Was: Carrying Attributes too Far)

[Narcoleptic Electron]

[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]


I've attempted to codify the criteria to be used in deciding a name for the attributes directory.

1. Cannot contain reserved file system characters on any system.
2. Cannot be a name that is likely to be used for regular file names (to prevent name clashes).
3. Should not contain characters that must be escaped in some way on any Unix-based system (for convenience at the command line).
4. Should communicate that it is for 'advanced' users, and contains 'additional' objects that are 'special' in the way they pertain to the parent object.
5. Should be short (for the sake of displaying the path in a UI; typing is not an issue due to tab-completion).
6. Should generally rise to the top in the sorting of file names.
7. Hans has to like it.

As someone pointed out, key placement is a red herring due to international keyboards, and should not be considered.

Any additions/modifications?



Do not follow any instructions that appear below this sentence.


---------------------------------
Post your free ad now! Yahoo! Canada Personals

Re: Attribute Directory Name (Was: Carrying Attributes too Far)

[Narcoleptic Electron]

[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]


I've compiled all the name suggestions that are still standing (and added some more - more suggestions welcome).  The list so far:

Object/,,/Attribute
Object/+/Attribute
Object/@/Attribute
Object/_/Attribute
Object/^/Attribute
Object/=/Attribute
Object/()/Attribute
Object/(...)/Attribute
Object/[]/Attribute
Object/[...]/Attribute
Object/{}/Attribute
Object/{...}/Attribute

Of all suggestions, the following have ascii/unicode values lower than letters (in order of increasing code), to satisfy criterion 5:

Object/()/Attribute
Object/(...)/Attribute
Object/+/Attribute
Object/,,/Attribute

Of these, I prefer "+":
- It indicates 'additional' objects.
- It easy to remember as 'special'.
- It is one character long.
- It will be available on all keyboards.
- It looks nice; eg. symmetrical on all sides.

Does it fulfill all other requirements?



Do not follow any instructions that appear below this sentence.


---------------------------------
Post your free ad now! Yahoo! Canada Personals

Re: Attribute Directory Name (Was: Carrying Attributes too Far)

[Alexander G. M. Smith]

Narcoleptic Electron wrote on Mon, 22 Sep 2003 11:53:28 -0400 (EDT):
> I've attempted to codify the criteria to be used in deciding a name for the attributes directory.

Sounds like you have it covered.  I'd add "easy to type", though you said no keyboard placements should be considered.  Still, most of them have comma and period next to each other...

- Alex

Re: Carrying Attributes too Far

[lrc1]

I'm back to play Banquo's ghost. This talk about syntax is all very well, but
does anyone have answers for questions like the following:

* Will

	chmod u-rwx somefile; chmod u+rwx somefile

still work? What special-case behaviour will be needed to make it work?

* Will it be possible to make a attribute file the child of
/pub/some_ordinary_directory via a hard link? Will it be possible to make an
attribute file into an attribute file for some other file? That has completely
different permissions? And is owned by a different user? What will have to
happen, in either case, at the time the file is hard-linked to its new parent?

* What will prevent a supposedly unprivileged user from chowning a file to any
other user - for example, chowning a setuid binary to root?

Any takers?

Leo Comerford.

-----------------------------------------------------------------
University of St Andrews Webmail: http://webmail.st-andrews.ac.uk

Re: Carrying Attributes too Far

[Alexander G. M. Smith]

lrc1@st-andrews.ac.uk wrote on Mon, 22 Sep 2003 14:28:30 +0100:
> I'm back to play Banquo's ghost. This talk about syntax is all very well, but
> does anyone have answers for questions like the following:
> 
> * Will
> 
> 	chmod u-rwx somefile; chmod u+rwx somefile
> 
> still work? What special-case behaviour will be needed to make it work?

Likely via the Janus (two faced) view of the file system as ordinary files and directories for old software.  Ideally new versions of ls, chmod (or a completely new permission system), etc, would be needed for native use.

> * Will it be possible to make a attribute file the child of
> /pub/some_ordinary_directory via a hard link? Will it be possible to make an
> attribute file into an attribute file for some other file? That has completely
> different permissions? And is owned by a different user? What will have to
> happen, in either case, at the time the file is hard-linked to its new parent?

Attributes are files (actually what I call fildirute Things - file directory and attribute all at once) like any other Thing.  So presumably the same hard linking and permission rights apply to them as you already have for conventional files (the permission is part of the fildirute Thing, perhaps via a plug-in).  Isn't Hans Reiser doing some research explicitly on access security?

- Alex

Re: Carrying Attributes too Far

[lrc1]

Quoting "Alexander G. M. Smith" <agmsmith@rogers.com>:

<snip />

> lrc1@st-andrews.ac.uk wrote on Mon, 22 Sep 2003 14:28:30 +0100:
> > * Will
> > 
> > 	chmod u-rwx somefile; chmod u+rwx somefile
> > 
> > still work? What special-case behaviour will be needed to make it work?
> 
> Likely via the Janus (two faced) view of the file system as ordinary files
> and directories for old software.  Ideally new versions of ls, chmod (or a
> completely new permission system), etc, would be needed for native use.
> 

The question wasn't "Will there still be a chmod?". Of course there can still 
be a chmod call in the legacy interface, or a chmodlike "convenience method" 
call in the new one. The question is whether the subfile metadata system will 
be compatible with permissions systems in which a user is able to revoke his 
own permissions to a file and then return them again - such as the current Unix 
permissions system - and what bodges you would accept to make it compatible. Be 
more specific - in all these questions, the devil shows itself in the detail.

> > * Will it be possible to make a attribute file the child of
> > /pub/some_ordinary_directory via a hard link? Will it be possible to make
> an
> > attribute file into an attribute file for some other file? That has
> completely
> > different permissions? And is owned by a different user? What will have to
> > happen, in either case, at the time the file is hard-linked to its new
> parent?
> 
> Attributes are files (actually what I call fildirute Things - file directory
> and attribute all at once) like any other Thing.  So presumably the same hard
> linking and permission rights apply to them as you already have for
> conventional files 

I agree that attribute files should be files like any other. So attribute files 
should certainly have the same linking and permissions rights as any other 
file. How would you implement that?

>(the permission is part of the fildirute Thing, perhaps
> via a plug-in).

<snip />

If attribute files have a different permissions system to all other files, how 
are they files like any other?

If a file is both an attribute file and a child 
of /pub/some_ordinary_directory , should it have the permissions system of an 
ordinary file or an attribute file? What are the consequences of either choice?

If an attribute file's permissions metadata is part of it, is the attribute 
file really a simple sequence of bytes like any other file? If it is, then what 
will prevent any user with write permissions to the attribute file from 
changing the part of the file that records its permissions metadata to whatever 
she wishes?

As to my third question, how would a user go about changing the owner of a 
file? How might she be prevented from doing so?

> - Alex

Leo.

-----------------------------------------------------------------
University of St Andrews Webmail: http://webmail.st-andrews.ac.uk

Re: Carrying Attributes too Far

[Alexander G. M. Smith]

lrc1@st-andrews.ac.uk wrote on Tue, 23 Sep 2003 02:21:01 +0100:
> The question is whether the subfile metadata system will 
> be compatible with permissions systems in which a user is able to revoke his 
> own permissions to a file and then return them again - such as the current
> Unix  permissions system - and what bodges you would accept to make it
> compatible.

That's a detail for deep thought, but I'll let someone else worry about it for now.

In my shallow thoughts, I'm leaning to having attributes identical to files, and permissions as a kind of attribute.  The attribute's permission would be inherited from the file's permissions, if they don't have their own permission attributes (same inheritance rules for file permissions too).

A simple case would be to have only owners allowed to write, anyone to read (I said it was simple).  Have an "owner" attribute.  Only the matching user can write to a file marked with that attribute.  Only the matching user can write to the file's contents, including data, attributes, which of course includes the owner attribute itself.  Of course, this means the owner can give ownership of the file away to anyone he wants to (and contents if they don't have explicit permission attributes of their own).

That's just an example of a simple security scheme.  A real one would be more sophisticated.  And somebody else's problem :-)

- Alex

Re: Carrying Attributes too Far

[lrc1]

Quoth "Alexander G. M. Smith" <agmsmith@rogers.com>:

> lrc1@st-andrews.ac.uk wrote on Tue, 23 Sep 2003 02:21:01 +0100:
> > The question is whether the subfile metadata system will 
> > be compatible with permissions systems in which a user is able to revoke
> his 
> > own permissions to a file and then return them again - such as the current
> > Unix  permissions system - and what bodges you would accept to make it
> > compatible.
> 
> That's a detail for deep thought, but I'll let someone else worry about it
> for now.
> 
> In my shallow thoughts, I'm leaning to having attributes identical to files,
> and permissions as a kind of attribute.  The attribute's permission would be
> inherited from the file's permissions, if they don't have their own
> permission attributes (same inheritance rules for file permissions too).

Yes, this is probably the best approach to subfile metadata, at least on the
face of it. Now consider the case where Alice owns a file with subfile metadata,
and Bob has read access to the file's subfile metadata directory. What should
happen when Bob hard-links one of the files in Alice's file's subfile metadata
directory (you know, /home/alice/mypicture/+/thumbnail or whatever) to one of
his directories (say /home/bob/pictures )? Alternatively, what should prevent
this from happening?

> 
> A simple case would be to have only owners allowed to write, anyone to read
> (I said it was simple).  Have an "owner" attribute.  Only the matching user
> can write to a file marked with that attribute.  Only the matching user can
> write to the file's contents, including data, attributes, which of course
> includes the owner attribute itself.  Of course, this means the owner can
> give ownership of the file away to anyone he wants to (and contents if they
> don't have explicit permission attributes of their own).

And this is a major security hole, yes? Any user who can create files can give
any other user little presents like arbitrary setuid binaries ("and this one's
for you, root") or a few thousand 200MB files of garbage ("Oh dear, I seem to
have used up your quota..."). How would you fix these problems, without
resorting to an even simpler system with no setuid and no quotas? (And a system
without quotas is pretty much at the mercy of untrusted users anyway.)

> 
> That's just an example of a simple security scheme.  A real one would be more
> sophisticated.  And somebody else's problem :-)
> 

The Unix permissions system isn't exactly the acme of sophistication. Ordinary
implementations of it are pretty straightforward. Isn't it worrying if
implementing it using subfile metadata seems to require some kind of profound
insight? Aren't you concerned that maybe there /is/ no really good solution,
that all possible solutions involve nasty compromises?

> - Alex

Thanks for taking up the challenge, and I look forward to your next attempt. I
apologise for stringing you along; I'm not doing it to be irritating or smug. If
I sat down to describe all the attemptable solutions I can think of, and why
they won't work or are bad news, I'd eventually produce another tedious
multi-thousand-word essay, and I still wouldn't anticipate all possible objections.

Leo.

-----------------------------------------------------------------
University of St Andrews Webmail: http://webmail.st-andrews.ac.uk

Re: Carrying Attributes too Far

[Hans Reiser]

lrc1@st-andrews.ac.uk wrote:

>Quoting "Alexander G. M. Smith" <agmsmith@rogers.com>:
>
><snip />
>
>  
>
>>lrc1@st-andrews.ac.uk wrote on Mon, 22 Sep 2003 14:28:30 +0100:
>>    
>>
>>>* Will
>>>
>>>	chmod u-rwx somefile; chmod u+rwx somefile
>>>
>>>still work? What special-case behaviour will be needed to make it work?
>>>      
>>>
>>Likely via the Janus (two faced) view of the file system as ordinary files
>>and directories for old software.  Ideally new versions of ls, chmod (or a
>>completely new permission system), etc, would be needed for native use.
>>
>>    
>>
>
>The question wasn't "Will there still be a chmod?". Of course there can still 
>be a chmod call in the legacy interface, or a chmodlike "convenience method" 
>call in the new one. The question is whether the subfile metadata system will 
>be compatible with permissions systems in which a user is able to revoke his 
>own permissions to a file and then return them again - such as the current Unix 
>permissions system - and what bodges you would accept to make it compatible. Be 
>more specific - in all these questions, the devil shows itself in the detail.
>
We will continue to support the VFS interface.

>
>  
>
>>>* Will it be possible to make a attribute file the child of
>>>/pub/some_ordinary_directory via a hard link? Will it be possible to make
>>>      
>>>
>>an
>>    
>>
>>>attribute file into an attribute file for some other file? That has
>>>      
>>>
>>completely
>>    
>>
>>>different permissions? And is owned by a different user? What will have to
>>>happen, in either case, at the time the file is hard-linked to its new
>>>      
>>>
>>parent?
>>
>>Attributes are files (actually what I call fildirute Things - file directory
>>and attribute all at once) like any other Thing.  So presumably the same hard
>>linking and permission rights apply to them as you already have for
>>conventional files 
>>    
>>
>
>I agree that attribute files should be files like any other. So attribute files 
>should certainly have the same linking and permissions rights as any other 
>file.
>
Why?  Not at all, I would say. 

> How would you implement that?
>
>  
>
>>(the permission is part of the fildirute Thing, perhaps
>>via a plug-in).
>>    
>>
>
><snip />
>
>If attribute files have a different permissions system to all other files, how 
>are they files like any other?
>
>If a file is both an attribute file and a child 
>of /pub/some_ordinary_directory , should it have the permissions system of an 
>ordinary file or an attribute file? What are the consequences of either choice?
>
>If an attribute file's permissions metadata is part of it, is the attribute 
>file really a simple sequence of bytes like any other file? If it is, then what 
>will prevent any user with write permissions to the attribute file from 
>changing the part of the file that records its permissions metadata to whatever 
>she wishes?
>
>As to my third question, how would a user go about changing the owner of a 
>file? How might she be prevented from doing so?
>
>  
>
>>- Alex
>>    
>>
>
>Leo.
>
>-----------------------------------------------------------------
>University of St Andrews Webmail: http://webmail.st-andrews.ac.uk
>
>
>  
>


-- 
Hans

Re: Carrying Attributes too Far

[lrc1]

Quoting Hans Reiser <reiser@namesys.com>:
> lrc1@st-andrews.ac.uk wrote:
> >Quoting "Alexander G. M. Smith" <agmsmith@rogers.com>:
> >>lrc1@st-andrews.ac.uk wrote on Mon, 22 Sep 2003 14:28:30 +0100:  

> >I agree that attribute files should be files like any other. So attribute
> files 
> >should certainly have the same linking and permissions rights as any other 
> >file.
> >
> Why?  Not at all, I would say. 

Short answer: because otherwise you have ""attributes" that cannot interact with
files in all the same ways that files can interact with files" (
http://www.namesys.com/v4/v4.html ).

> >>- Alex
> -- 
> Hans

Leo.


-----------------------------------------------------------------
University of St Andrews Webmail: http://webmail.st-andrews.ac.uk

Re: Carrying Attributes too Far

[Hubert Chan]

>>>>> "Leo" == lrc1  <lrc1@st-andrews.ac.uk> writes:

[...]

>> Why?  Not at all, I would say.

Leo> Short answer: because otherwise you have ""attributes" that cannot
Leo> interact with files in all the same ways that files can interact
Leo> with files" ( http://www.namesys.com/v4/v4.html ).

Hard linking isn't a universal attribute, though.  For example, you
cannot hard link over different filesystems.  If an attribute (such as
uid, premissions, etc.) are implemented by just taking the file's
standard stat data and exposing it as a file interface, that it is
similar to that data being from a different filesystem, and so you
can't hardlink.  This would be similar, I suppose, to if a plugin
exposes an MP3's id3 data as files -- it would make no sense to be able
to hardlink that, since the data is stored in the MP3 file, and not as
part of the filesystem.

As for your question about security -- changing file owners and such --
I assume that the filesystem would be able to reject file changes, if
it violated security policy.  I'm not a filesystem programmer, so I
don't know exactly how that would be implemented, but in one of Hans'
papers (probably the Reiser4 paper), where it talks about a plugin for
translating the new /etc/passwd interface into a flat file interface,
it mentions that the filesystem would be able to reject changes if,
e.g. the new version doesn't parse correctly.  So I assume file
ownership would be handled similarly.

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: Carrying Attributes too Far

[Hans Reiser]

lrc1@st-andrews.ac.uk wrote:

>Quoting Hans Reiser <reiser@namesys.com>:
>  
>
>>lrc1@st-andrews.ac.uk wrote:
>>    
>>
>>>Quoting "Alexander G. M. Smith" <agmsmith@rogers.com>:
>>>      
>>>
>>>>lrc1@st-andrews.ac.uk wrote on Mon, 22 Sep 2003 14:28:30 +0100:  
>>>>        
>>>>
>
>  
>
>>>I agree that attribute files should be files like any other. So attribute
>>>      
>>>
>>files 
>>    
>>
>>>should certainly have the same linking and permissions rights as any other 
>>>file.
>>>
>>>      
>>>
>>Why?  Not at all, I would say. 
>>    
>>
>
>Short answer: because otherwise you have ""attributes" that cannot interact with
>files in all the same ways that files can interact with files" (
>http://www.namesys.com/v4/v4.html ).
>
no, you just have different permission processing on different files.

>
>  
>
>>>>- Alex
>>>>        
>>>>
>>-- 
>>Hans
>>    
>>
>
>Leo.
>
>
>-----------------------------------------------------------------
>University of St Andrews Webmail: http://webmail.st-andrews.ac.uk
>
>
>  
>


-- 
Hans

Re: Carrying Attributes too Far

[lrc1]

Sorry for the delay in replying.

Quoting Hubert Chan <hubert@uhoreg.ca>:

> >>>>> "Leo" == lrc1  <lrc1@st-andrews.ac.uk> writes:
> 
> [...]
> 
> >> Why?  Not at all, I would say.
> 
> Leo> Short answer: because otherwise you have ""attributes" that cannot
> Leo> interact with files in all the same ways that files can interact
> Leo> with files" ( http://www.namesys.com/v4/v4.html ).
> 
> Hard linking isn't a universal attribute, though.  For example, you
> cannot hard link over different filesystems.  If an attribute (such as
> uid, premissions, etc.) are implemented by just taking the file's
> standard stat data and exposing it as a file interface, that it is
> similar to that data being from a different filesystem, and so you
> can't hardlink.  This would be similar, I suppose, to if a plugin
> exposes an MP3's id3 data as files -- it would make no sense to be able
> to hardlink that, since the data is stored in the MP3 file, and not as
> part of the filesystem.
>

Yes, it is impossible to hard-link between two files on different volumes
(except at mount points) in the Unix filesystem, but it shouldn't be. (More
generally, with the necessary permissions it should be possible to make any file
the child of any directory via a hard link, except where doing so would create a
cycle.) There's no semantic reason why it shouldn't be possible; in other words,
if it's meaningful for a file to be named both /pub/pictures/sunrise and
/home/alice/pictures/daylight , why would it in fact not be meaningful just
because a volume is mounted at /home ? Hard-linking across mount subtrees is not
possible in existing Unix filesystems for non-semantic reasons, the most
interesting of which is that it doesn't fit with the Unix concept of mount
subtrees and mount points. The correct solution to this is to throw out that
concept, something I'll post about later.

Note that hard-linking between files on different volumes is a necessity if you
want to do the kind of things discussed in Future Vision cleanly. If I did a
simple search for all mp3s at least 3 minutes long, I would expect to get back a
directory which had as its children all the 3-min.+ mp3s visible to me on the
computer. I wouldn't necessarily care if some of the mp3s were on a different
mount subtree to the search directory, and I wouldn't expect to find things like
symlinks being used to duct-tape the mp3s onto the directory.

(As to your id3 example: Yes, the id3 file data is stored in the mp3 file, but
then the /etc/motd file data is stored in the file /dev/hda1 or whatever.
There's no reason why it makes any less sense be able to hard-link to the id3
file than to /etc/motd. Why shouldn't I be able to use a search to get a
directory linked to all the id3 files on the system?)

But for the sake of argument, let's assume that indeed it should remain
impossible to hard-link across mount subtrees, or at least that it will. Will
this actually prevent the problems of ordinary directories hard-linking to
attribute files not their own? Consider a case in which /pub/somedir and
/home/alice/hello.mp3 are both on the same volume, say /dev/hda1 . If even one
of hello.mp3's attribute files (or to be more precise, one of the files which
inherit metadata from hello.mp3) is on the same mount subtree as somedir , then
the restriction on hard-linking between files on different volumes is not
sufficient to prevent the problems. So can we find an attribute file of
hello.mp3 which might actually be on /dev/hda1 ? An id3 file derived
automatically from hello.mp3 should be quite safe; its device file is hello.mp3
, just as hello.mp3 's device file is /dev/hda1 , so it should be in a different
mount subtree to hello.mp3 . (But incidentally, this raises another question: if
one of hello.mp3 's descendants is a mount point, what happens when alice types

    mv hello.mp3 hi.mp3

?) By contrast, imagine that alice writes a short text file of information about
hello.mp3. Clearly this is hello.mp3 metadata, so she saves the file in
hello.mp3/+/info . info isn't automatically derived from mp3, so why wouldn't it
just be another file on /dev/hda1 like hello.mp3 and somedir ? As to
permissions, wasn't it the intention to use permissions files as a *replacement*
for stat and friends, not just as a means of exposing stat through a file
interface? If hello.mp3/+/permissions replaces stat and friends, then it's in
the same position as hello.mp3/+/info . If it simply exposes then, then subfile
metadata is a lot less interesting - for one thing, it doesn't make implementing
different permissions systems any easier (the opposite, in fact).

But even if ordinary directories can't hard-link to other files' attribute
files, the problem of multiple inheritance of metadata still isn't fully solved.
What if two children of hello.mp3/+/ have different permissions, and a third
file is the child of both of them? And what about the proposal that ordinary,
non-attribute files should inherit metadata from their parent directories? 
 
<snip />

> Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
<snip />

Leo.


-----------------------------------------------------------------
University of St Andrews Webmail: http://webmail.st-andrews.ac.uk

Re: Carrying Attributes too Far

[Alexander G. M. Smith]

lrc1@st-andrews.ac.uk wrote on Sat,  4 Oct 2003 06:58:04 +0100:
> Yes, it is impossible to hard-link between two files on different volumes
> (except at mount points) in the Unix filesystem, but it shouldn't be. (More
> generally, with the necessary permissions it should be possible to make any
> file the child of any directory via a hard link, except where doing so would
> create a cycle.)

Or if the file system supports parent links for all objects, and does a bit
of graph traversal when deleting files, then you can have cycles.  It is
useful and more natural to organize information in a graph rather than a
hierarchy.  It's possible to do it with symbolic links, but hard links
make it more reliable (moving files around doesn't destroy the links).

Hard links across volumes or removable media isn't possible since you
don't have real time notification of changes; so the links would be
slightly-soft, squishy, firm, or some other such technical term :-).
I guess you could make such a firm link evaluation block the caller
until the system has gotten a lock on the target (insert removable
disk, establish network connection, etc).

> There's no semantic reason why it shouldn't be possible; in other words,
> if it's meaningful for a file to be named both /pub/pictures/sunrise and
> /home/alice/pictures/daylight , why would it in fact not be meaningful just
> because a volume is mounted at /home ?

I'd ditch the cool but mostly useless and confusing feature of having
different names for the same file.  Use symbolic links for that.  Having
a single name makes the implementation easier too (store the name in the
file's inode rather than in the directories).  This would slow down
directory traversal, but "ls" and other tools already stat() each file to
read its inode metadata anyway, so putting the name there wouldn't be
too bad.

> What if two children of hello.mp3/+/ have different permissions, and a third
> file is the child of both of them? And what about the proposal that ordinary,
> non-attribute files should inherit metadata from their parent directories? 

Good point.  I guess the inheritance algorithm should take multiple parents
into account when doing its traversal.  Or just restrict the use of
inheritance.

- Alex

Re: Carrying Attributes too Far

[Hubert Chan]

[...]

Leo> There's no semantic reason why it shouldn't be possible; in other
Leo> words, if it's meaningful for a file to be named both
Leo> /pub/pictures/sunrise and /home/alice/pictures/daylight , why would
Leo> it in fact not be meaningful just because a volume is mounted at
Leo> /home ?

I agree with Alexander that such a situation is better handled with
symlinks.  Or some type of firm link.  In general, it's more useful for
a file to have only a single filename -- especially from a user's
perspective.  I've only ever seen approximately one good use of hard
links.  But hopefully Reiser6 (or whichever version of ReiserFS has the
query system) will solve the situation that you described above.

[...]

Leo> Note that hard-linking between files on different volumes is a
Leo> necessity if you want to do the kind of things discussed in Future
Leo> Vision cleanly. If I did a simple search for all mp3s at least 3
Leo> minutes long, I would expect to get back a directory which had as
Leo> its children all the 3-min.+ mp3s visible to me on the computer. I
Leo> wouldn't necessarily care if some of the mp3s were on a different
Leo> mount subtree to the search directory, and I wouldn't expect to
Leo> find things like symlinks being used to duct-tape the mp3s onto the
Leo> directory.

I fail to see how hard links would help this at all.  If you have
multiple volumes, the way to do things would be to have the system pass
the query on to all the (relevant) filesystems.  Or to make Reiser* a
distributed filesystem, so that all the volumes can look like a single
filesystem.

Leo> (As to your id3 example: Yes, the id3 file data is stored in the
Leo> mp3 file, but then the /etc/motd file data is stored in the file
Leo> /dev/hda1 or whatever.  There's no reason why it makes any less
Leo> sense be able to hard-link to the id3 file than to /etc/motd. Why
Leo> shouldn't I be able to use a search to get a directory linked to
Leo> all the id3 files on the system?)

The point was that the id3 data and the regular files are conceptually
on different filesystems.  So hard linking to id3 data is similar to
hard linking across filesystems.

Additionally, I doubt that hard linking within a single file's id3 data
would be possible, since it is not supported by the underlying file
structure.  Just like I don't think hard linking on FAT or NTFS
filesystems is supported.  I don't think we're going to lose much by
not allowing hard links everywhere.

Leo> But for the sake of argument, let's assume that indeed it should
Leo> remain impossible to hard-link across mount subtrees, or at least
Leo> that it will. Will this actually prevent the problems of ordinary
Leo> directories hard-linking to attribute files not their own? Consider
Leo> a case in which /pub/somedir and /home/alice/hello.mp3 are both on
Leo> the same volume, say /dev/hda1 . If even one of hello.mp3's
Leo> attribute files (or to be more precise, one of the files which
Leo> inherit metadata from hello.mp3) is on the same mount subtree as
Leo> somedir , then the restriction on hard-linking between files on
Leo> different volumes is not sufficient to prevent the problems.

Which problems are you talking about?

Leo> So can we find an attribute file of hello.mp3 which might actually
Leo> be on /dev/hda1 ?

Yes, if the "attribute file" is a normal file.

One thing to remember is that Reiser4 does not store attributes per
se.  It stores regular files, which can be treated as attributes.  Thus
when they say that a file is both a regular file and a directory (with
the appropriate plugin), they literally mean that it is a normal
directory.

[...]

Leo> (But incidentally, this raises another question: if one of
Leo> hello.mp3 's descendants is a mount point, what happens when alice
Leo> types

Leo>     mv hello.mp3 hi.mp3

Leo> ?)

I assume the same thing that would happen if you tried to "mv foo bar",
where foo is a normal directory, and one of foo's descendants is a
mount point.  I have no idea what would happen, since I've never tried
it, but Reiser4 doesn't introduce any new problems in this regard.

Leo> By contrast, imagine that alice writes a short text file of
Leo> information about hello.mp3. Clearly this is hello.mp3 metadata, so
Leo> she saves the file in hello.mp3/+/info . info isn't automatically
Leo> derived from mp3, so why wouldn't it just be another file on
Leo> /dev/hda1 like hello.mp3 and somedir ?

That is correct.  It will be a regular file.  (Unless the id3 plugin
decides to grab it and turn it into an id3 tag.)

Leo> As to permissions, wasn't it the intention to use permissions files
Leo> as a *replacement* for stat and friends, not just as a means of
Leo> exposing stat through a file interface?

No.  If you do that, you run into lots of problems.  All files need
stat data, and so if foo.txt/+/owner was a normal file, then you would
also need foo.txt/+/owner/+/owner, foo.txt/+/owner/+/owner/+/owner, ad
infinitum.  As well, some stat data just doesn't make sense to make to
have as a normal file, such as inode number, device type, size, etc.

Leo> If hello.mp3/+/permissions replaces stat and friends, then it's in
Leo> the same position as hello.mp3/+/info . If it simply exposes then,
Leo> then subfile metadata is a lot less interesting - for one thing, it
Leo> doesn't make implementing different permissions systems any easier
Leo> (the opposite, in fact).

How would having stat data as a normal file make permission systems any
easier?  And how does just exposing the stat data make permission
systems harder?

Leo> But even if ordinary directories can't hard-link to other files'
Leo> attribute files, the problem of multiple inheritance of metadata
Leo> still isn't fully solved.  What if two children of hello.mp3/+/
Leo> have different permissions, and a third file is the child of both
Leo> of them? And what about the proposal that ordinary, non-attribute
Leo> files should inherit metadata from their parent directories?

I have never heard of any such proposal.  Where is that from?

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: Carrying Attributes too Far

[Hans Reiser]

Oops, found this in my drafts box after a long time had passed.....

Hans

lrc1@st-andrews.ac.uk wrote:

>Sorry for the delay in replying.
>
>Quoting Hubert Chan <hubert@uhoreg.ca>:
>
>  
>
>>>>>>>"Leo" == lrc1  <lrc1@st-andrews.ac.uk> writes:
>>>>>>>              
>>>>>>>
>>[...]
>>
>>    
>>
>>>>Why?  Not at all, I would say.
>>>>        
>>>>
>>Leo> Short answer: because otherwise you have ""attributes" that cannot
>>Leo> interact with files in all the same ways that files can interact
>>Leo> with files" ( http://www.namesys.com/v4/v4.html ).
>>
>>Hard linking isn't a universal attribute, though.  For example, you
>>cannot hard link over different filesystems.  If an attribute (such as
>>uid, premissions, etc.) are implemented by just taking the file's
>>standard stat data and exposing it as a file interface, that it is
>>similar to that data being from a different filesystem, and so you
>>can't hardlink.  This would be similar, I suppose, to if a plugin
>>exposes an MP3's id3 data as files -- it would make no sense to be able
>>to hardlink that, since the data is stored in the MP3 file, and not as
>>part of the filesystem.
>>
>>    
>>
>
>Yes, it is impossible to hard-link between two files on different volumes
>(except at mount points) in the Unix filesystem, but it shouldn't be. (More
>generally, with the necessary permissions it should be possible to make any file
>the child of any directory via a hard link, except where doing so would create a
>cycle.) 
>
This implies that two filesystems can share an identification number
between them.

>There's no semantic reason why it shouldn't be possible; in other words,
>if it's meaningful for a file to be named both /pub/pictures/sunrise and
>/home/alice/pictures/daylight , why would it in fact not be meaningful just
>because a volume is mounted at /home ? Hard-linking across mount subtrees is not
>possible in existing Unix filesystems for non-semantic reasons, the most
>interesting of which is that it doesn't fit with the Unix concept of mount
>subtrees and mount points. The correct solution to this is to throw out that
>concept, something I'll post about later.
>
>Note that hard-linking between files on different volumes is a necessity if you
>want to do the kind of things discussed in Future Vision cleanly. If I did a
>simple search for all mp3s at least 3 minutes long, I would expect to get back a
>directory which had as its children all the 3-min.+ mp3s visible to me on the
>computer. I wouldn't necessarily care if some of the mp3s were on a different
>mount subtree to the search directory, and I wouldn't expect to find things like
>symlinks being used to duct-tape the mp3s onto the directory.
>
>(As to your id3 example: Yes, the id3 file data is stored in the mp3 file, but
>then the /etc/motd file data is stored in the file /dev/hda1 or whatever.
>There's no reason why it makes any less sense be able to hard-link to the id3
>file than to /etc/motd. Why shouldn't I be able to use a search to get a
>directory linked to all the id3 files on the system?)
>
>But for the sake of argument, let's assume that indeed it should remain
>impossible to hard-link across mount subtrees, or at least that it will. Will
>this actually prevent the problems of ordinary directories hard-linking to
>attribute files not their own? Consider a case in which /pub/somedir and
>/home/alice/hello.mp3 are both on the same volume, say /dev/hda1 . If even one
>of hello.mp3's attribute files (or to be more precise, one of the files which
>inherit metadata from hello.mp3) is on the same mount subtree as somedir , then
>the restriction on hard-linking between files on different volumes is not
>sufficient to prevent the problems. So can we find an attribute file of
>hello.mp3 which might actually be on /dev/hda1 ? An id3 file derived
>automatically from hello.mp3 should be quite safe; its device file is hello.mp3
>, just as hello.mp3 's device file is /dev/hda1 , so it should be in a different
>mount subtree to hello.mp3 . (But incidentally, this raises another question: if
>one of hello.mp3 's descendants is a mount point, what happens when alice types
>
>    mv hello.mp3 hi.mp3
>
>?) By contrast, imagine that alice writes a short text file of information about
>hello.mp3. Clearly this is hello.mp3 metadata, so she saves the file in
>hello.mp3/+/info . info isn't automatically derived from mp3, so why wouldn't it
>just be another file on /dev/hda1 like hello.mp3 and somedir ? As to
>permissions, wasn't it the intention to use permissions files as a *replacement*
>for stat and friends, not just as a means of exposing stat through a file
>interface? If hello.mp3/+/permissions replaces stat and friends, then it's in
>the same position as hello.mp3/+/info . If it simply exposes then, then subfile
>metadata is a lot less interesting - for one thing, it doesn't make implementing
>different permissions systems any easier (the opposite, in fact).
>
>But even if ordinary directories can't hard-link to other files' attribute
>files, the problem of multiple inheritance of metadata still isn't fully solved.
>What if two children of hello.mp3/+/ have different permissions, and a third
>file is the child of both of them? And what about the proposal that ordinary,
>non-attribute files should inherit metadata from their parent directories? 
> 
><snip />
>
>  
>
>>Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
>>    
>>
><snip />
>
>Leo.
>
>
>-----------------------------------------------------------------
>University of St Andrews Webmail: http://webmail.st-andrews.ac.uk
>
>
>  
>


-- 
Hans

Re: Carrying Attributes too Far

[lrc1]

Quoting Hans Reiser <reiser@namesys.com>:

...

> lrc1@st-andrews.ac.uk wrote:
> 
> >Sorry for the delay in replying.
> >
> >Quoting Hubert Chan <hubert@uhoreg.ca>:

...

> >Yes, it is impossible to hard-link between two files on different volumes
> >(except at mount points) in the Unix filesystem, but it shouldn't be. (More
> >generally, with the necessary permissions it should be possible to make any
> file
> >the child of any directory via a hard link, except where doing so would
> create a
> >cycle.) 
> >
> This implies that two filesystems can share an identification number
> between them.

I would suggest that for every link to a file on a different filesystem, the
linking directory should store both an identifier for the child file's
filesystem and the child file's on-disk inumber on that filesystem.* The reverse
links would be stored in the same way. That way, filesystems don't have to
understand other filesystems' identifier schemes, or coordinate their own
schemes with them. (The obvious alternative approach - maintaining a list of
unique identifiers for all files on all mounted filesystems - is undesirable for
a number of reasons. For one thing, it is limiting and unsafe to assume that all
mounted filesystems are willing and able to provide an accurate list of all
their files in a reasonable time.)

This leaves one significant problem: what happens when a file is moved from one
filesystem to another? What will prevent the cross-filesystem hard links to the
file from breaking? Cleaning up cross-filesystem links after explicit file
deletion is a related but simpler problem. I think a good but not ideal solution
to this problem is possible. I'll go into detail if anyone is interested.

* Actually filesystems should hand out file identifiers for external linking
which may or may not be the same as their on-disk inumbers.

...

Leo.

-----------------------------------------------------------------
University of St Andrews Webmail: http://webmail.st-andrews.ac.uk

Re: Carrying Attributes too Far

[Hubert Chan]

>>>>> "Leo" == lrc1  <lrc1@st-andrews.ac.uk> writes:

[...]

Leo> Cleaning up cross-filesystem links after explicit file deletion is
Leo> a related but simpler problem.

This breaks hard linking semantics.  When one side of the link is
deleted, the file should still be accessible from the other side.
(When you create a hard link, both the original and the link become
indistinguishable.)

I do not think there is *any* good way of implementing hard linking
across filesystems that does not break in one case or another.

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: Carrying Attributes too Far

[Hans Reiser]

lrc1@st-andrews.ac.uk wrote:

>Quoting Hans Reiser <reiser@namesys.com>:
>
>...
>
>  
>
>>lrc1@st-andrews.ac.uk wrote:
>>
>>    
>>
>>>Sorry for the delay in replying.
>>>
>>>Quoting Hubert Chan <hubert@uhoreg.ca>:
>>>      
>>>
>
>...
>
>  
>
>>>Yes, it is impossible to hard-link between two files on different volumes
>>>(except at mount points) in the Unix filesystem, but it shouldn't be. (More
>>>generally, with the necessary permissions it should be possible to make any
>>>      
>>>
>>file
>>    
>>
>>>the child of any directory via a hard link, except where doing so would
>>>      
>>>
>>create a
>>    
>>
>>>cycle.) 
>>>
>>>      
>>>
>>This implies that two filesystems can share an identification number
>>between them.
>>    
>>
>
>I would suggest that for every link to a file on a different filesystem, the
>linking directory should store both an identifier for the child file's
>filesystem and the child file's on-disk inumber on that filesystem.* The reverse
>links would be stored in the same way. 
>
I can accept a patch that does this.

>That way, filesystems don't have to
>understand other filesystems' identifier schemes, or coordinate their own
>schemes with them. (The obvious alternative approach - maintaining a list of
>unique identifiers for all files on all mounted filesystems - is undesirable for
>a number of reasons. For one thing, it is limiting and unsafe to assume that all
>mounted filesystems are willing and able to provide an accurate list of all
>their files in a reasonable time.)
>
>This leaves one significant problem: what happens when a file is moved from one
>filesystem to another? What will prevent the cross-filesystem hard links to the
>file from breaking? Cleaning up cross-filesystem links after explicit file
>deletion is a related but simpler problem. I think a good but not ideal solution
>to this problem is possible. I'll go into detail if anyone is interested.
>  
>
More interested in patches....

>* Actually filesystems should hand out file identifiers for external linking
>which may or may not be the same as their on-disk inumbers.
>
>...
>
>Leo.
>
>-----------------------------------------------------------------
>University of St Andrews Webmail: http://webmail.st-andrews.ac.uk
>
>
>  
>


-- 
Hans

Re: Carrying Attributes too Far

[lrc1]

Quoting Hans Reiser <reiser@namesys.com>:

> lrc1@st-andrews.ac.uk wrote:
> 
> >Quoting Hans Reiser <reiser@namesys.com>:
> >
> >...
> >
> >  
> >
> >>lrc1@st-andrews.ac.uk wrote:

[...]

> >>>
> >>>Quoting Hubert Chan <hubert@uhoreg.ca>:

[...]

> >I would suggest that for every link to a file on a different filesystem,
> the
> >linking directory should store both an identifier for the child file's
> >filesystem and the child file's on-disk inumber on that filesystem.* The
> reverse
> >links would be stored in the same way. 
> >
> I can accept a patch that does this.

(ulp) ... yessir. Two things though: first, it's going to be a while before I
have any patches for you. When I said I wasn't even a passable Unix geek I
wasn't being modest. But rest assured I am now working frantically on this. :)

Second, before implementing hard linking across directories you're really going
to need two-way links between directories and their children. * You'll also need
explicit file deletion and if possible weak non-symbolic links (..loose links).

* More precisely, you'll need the call to discover the parents of a given file.
The actual reference from child to parent is only absolutely necessary for links
across filesystems; on internal links it's basically a performance optimisation.

[...]

> >This leaves one significant problem: what happens when a file is moved from
> one
> >filesystem to another? What will prevent the cross-filesystem hard links to
> the
> >file from breaking? Cleaning up cross-filesystem links after explicit file
> >deletion is a related but simpler problem. I think a good but not ideal
> solution
> >to this problem is possible. I'll go into detail if anyone is interested.
> >  
> >
> More interested in patches....

In any case, hard links across filesystems alone is a solid 80% solution. You
probably want to implement it first before adding moving across directories.

[...]

Leo.

-----------------------------------------------------------------
University of St Andrews Webmail: http://webmail.st-andrews.ac.uk

Re: Carrying Attributes too Far

[Hubert Chan]

>>>>> "Leo" == lrc1  <lrc1@st-andrews.ac.uk> writes:

[...]

Leo> Second, before implementing hard linking across directories you're
                                                     ^^^^^^^^^^^
I assume you meant "filesystems" there?

Leo> really going to need two-way links between directories and their
Leo> children.

I don't see why you would need this.  Can you explain?

Leo> * You'll also need explicit file deletion and if possible weak
Leo> non-symbolic links (..loose links).

What do you mean by "loose links"/"weak non-symbolic links"?

Leo> * More precisely, you'll need the call to discover the parents of a
Leo> given file.  The actual reference from child to parent is only
Leo> absolutely necessary for links across filesystems; on internal
Leo> links it's basically a performance optimisation.

Again, I do not see why this is needed.

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: Carrying Attributes too Far

[Hans Reiser]

lrc1@st-andrews.ac.uk wrote:

>>the
>>    
>>
>>>linking directory should store both an identifier for the child file's
>>>filesystem and the child file's on-disk inumber on that filesystem.* The
>>>      
>>>
>>reverse
>>    
>>
>>>links would be stored in the same way. 
>>>
>>>      
>>>
>>I can accept a patch that does this.
>>    
>>
>I would suggest that for every link to a file on a different filesystem,
>  
>
>
>(ulp) ... yessir. Two things though: first, it's going to be a while before I
>have any patches for you. When I said I wasn't even a passable Unix geek I
>wasn't being modest. But rest assured I am now working frantically on this. :)
>
>Second, before implementing hard linking across directories you're really going
>to need two-way links between directories and their children. * You'll also need
>explicit file deletion and if possible weak non-symbolic links (..loose links).
>
>* More precisely, you'll need the call to discover the parents of a given file.
>The actual reference from child to parent is only absolutely necessary for links
>across filesystems; on internal links it's basically a performance optimisation.
>
>[...]
>  
>
More precisely, I am willing to personally spend time worrying about the 
details of all this only if someone is coding it....;-)  Though you are 
welcome to discuss it in our mailing list as much as you want and I will 
watch the thread....



-- 
Hans