"Metas"

"Metas"

[Christian Iversen]

Just a thought. Who on this list does NOT support "..." instead of metas?

...except from Hans ;-)

-- 
Regards,
Christian Iversen

Re: "Metas"

[Alexander G. M. Smith]

Christian Iversen wrote on Mon, 5 Apr 2004 02:12:05 +0200:
> Just a thought. Who on this list does NOT support "..." instead of metas?

Windows has that as the parent of the parent directory.

I also use it as the second parent directory in a file system that allows multiple parents, .... is the third parent directory, and so on.  But that doesn't really matter since nobody's making much use of multiple parents yet.

- Alex

Re: "Metas"

[Christian Iversen]

On Monday 05 April 2004 02:32, Alexander G. M. Smith wrote:
> Christian Iversen wrote on Mon, 5 Apr 2004 02:12:05 +0200:
> > Just a thought. Who on this list does NOT support "..." instead of metas?
>
> Windows has that as the parent of the parent directory.

Not consistently - i.e only in Win2K and newer. DOS/Win9x used "dir ..." for 
"show me all directories". 

> I also use it as the second parent directory in a file system that allows
> multiple parents, .... is the third parent directory, and so on.  But that
> doesn't really matter since nobody's making much use of multiple parents
> yet.

And it would be perfectly possible to access that same dir by ../.. still, 
wouldn't it? :)

-- 
Regards,
Christian Iversen

Re: "Metas"

[Hubert Chan]

>>>>> "Christian" == Christian Iversen <chrivers@iversen-net.dk> writes:

Christian> Just a thought. Who on this list does NOT support "..."
Christian> instead of metas?

I personally don't like the way that "..." looks.  IMHO, it's just ugly.
But that's my main complaint with it, and it's just an opinion.

Hmm.  Looking at http://namesys.com/v4/pseudo.html just reminded me that
the string "..." is also used as a placeholder for multiple unspecified
items (name1/name2/name3/ ... /nameN/name), and so writing "..." in a
manual/instructions could be confusing.

While I would much prefer ..metas or even .metas over plain metas, I
would have to agree with Hans that it is extremely unlikely that anyone
would actually use such a name.  I don't think it's a showstopper.

-- 
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: "Metas"

[Marcelo Pacheco]

Novell allows to move 2 directories up ... to move 3 ...., and so on.
I've been following this discussion almost in disbelief of how many e-mails 
have been exchanged on this matter. Please, just vote, each and every one 
that is on the list that has an opinion, then let Namesys decide.

I vote for ..meta, .meta is fine with me to. I don't want meta to ever colide 
with a normal file/directory name.

I will not reply to any replies on this matters, and I ask people only to 
vote. Everybody's point of view have been more than shown, it's not the 
number of e-mails that will change Namesys position.

Marcelo Pacheco

On Sunday 04 April 2004 21:32, Alexander G. M. Smith wrote:
> Christian Iversen wrote on Mon, 5 Apr 2004 02:12:05 +0200:
> > Just a thought. Who on this list does NOT support "..." instead of metas?
>
> Windows has that as the parent of the parent directory.
>
> I also use it as the second parent directory in a file system that allows
> multiple parents, .... is the third parent directory, and so on.  But that
> doesn't really matter since nobody's making much use of multiple parents
> yet.
>
> - Alex

Re: "Metas"

[Hans Reiser]

Alexander G. M. Smith wrote:

>Christian Iversen wrote on Mon, 5 Apr 2004 02:12:05 +0200:
>  
>
>>Just a thought. Who on this list does NOT support "..." instead of metas?
>>    
>>
I care more about the persons who have never used Linux, and what they 
find intuitive.

>
>Windows has that as the parent of the parent directory.
>
>I also use it as the second parent directory in a file system that allows multiple parents, .... is the third parent directory, and so on.  But that doesn't really matter since nobody's making much use of multiple parents yet.
>
>- Alex
>
>
>  
>


-- 
Hans

Re: "Metas"

[Narcoleptic Electron]

Hans Reiser wrote: 

> >Christian Iversen wrote on Mon, 5 Apr 2004 02:12:05
> +0200:
> >
> >Just a thought. Who on this list does NOT support
> >"..." instead of metas?
>
> I care more about the persons who have never used
> Linux, and what they 
> find intuitive.

So do I.

"Metas" has little meaning in most languages (and
"goals" in some, which is misleading and likely to
clash).

An ellipsis ("...") means "and more" or "additional
information" in almost all languages (if not all).

There may be other arguments against ellipsis, but
this one does not hold.


______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

Re: "Metas"

[Hans Reiser]

Narcoleptic Electron wrote:

>Hans Reiser wrote: 
>
>  
>
>>>Christian Iversen wrote on Mon, 5 Apr 2004 02:12:05
>>>      
>>>
>>+0200:
>>    
>>
>>>Just a thought. Who on this list does NOT support
>>>"..." instead of metas?
>>>      
>>>
>>I care more about the persons who have never used
>>Linux, and what they 
>>find intuitive.
>>    
>>
>
>So do I.
>
>"Metas" has little meaning in most languages (and
>"goals" in some, which is misleading and likely to
>clash).
>
>An ellipsis ("...") means "and more" or "additional
>information" in almost all languages (if not all).
>
>There may be other arguments against ellipsis, but
>this one does not hold.
>
>
>______________________________________________________________________ 
>Post your free ad now! http://personals.yahoo.ca
>
>
>  
>
we could maybe go for ..../ but for reasons I cannot articulate I lack 
enthusiasm for it and prefer metas as a hidden pseudo-directory

-- 
Hans

Re: "Metas"

[James H. Cloos Jr.]

Just to add to this, as someone who is eagerly anticipating r4:

While .metas or .meta might be OK, metas or meta is not.

No reserved name should lack an initial dot.

Netapp's .snapshot dir was mentioned in this tread.  That only works
because of the initial dot in the name.  Had it been just snapshot
or snapshots it would not have gone over nearly as well.

I cannot see even those w/o a posix background finding metas any
easier than .metas.

I also suspect you will find it easier to get past Linus.

-JimC
-- 
James H. Cloos, Jr. <cloos@jhcloos.com> <http://jhcloos.com>

Re: "Metas"

[Narcoleptic Electron]

"James H. Cloos Jr." wrote: 

> While .metas or .meta might be OK, metas or meta is
> not.
> 
> No reserved name should lack an initial dot.
> 
> Netapp's .snapshot dir was mentioned in this tread. 
> That only works
> because of the initial dot in the name.  Had it been
> just snapshot
> or snapshots it would not have gone over nearly as
> well.
> 
> I cannot see even those w/o a posix background
> finding metas any
> easier than .metas.
> 
> I also suspect you will find it easier to get past
> Linus.

I don't think I've heard a single person, except Hans,
voice any support for "metas".

It seems that the most widely supported name thus far
is "...".


______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

Re: "Metas"

[Grant Miner]

> 
> I don't think I've heard a single person, except Hans,
> voice any support for "metas".

I like "metas".

> 
> It seems that the most widely supported name thus far
> is "...".
> 
> 
> ______________________________________________________________________ 
> Post your free ad now! http://personals.yahoo.ca
> 

Maybe "props" would be a good name?  It is short for properties, which 
is synonymous with metadata and attributes (oops, I used a heretical 
word! :)

Re: "Metas"

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Narcoleptic Electron wrote:
[...]
| It seems that the most widely supported name thus far
| is "...".

As far as '...', since I haven't had an opinion yet -- I believe that a
'...' would be nice, but the usage of '.' and '..' is so generic
(current/parent dir) that we want to make sure '...' is just as generic
and universally useful.  Otherwise, we may end up with things like
'...................' in a few years.

Also, I can't see ... as being any easier than ..metas (or, of course,
.metas).  At the shell, it's typing "<dot> <dot> <dot>" instead of
"<dot> m <tab>" or even "<dot> <dot> m <tab>".  Anywhere but the shell,
and there's really no point, unless we're afraid of hitting some limit
on filename length that I'm not aware of -- in which case, this is not
the place to optimize.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQIBbLXgHNmZLgCUhAQJN0Q//aGv8BLyqW/LzsdHSl3MxXLoBmT8ah/W+
hGQn+j+IUaCLuSyslE9Z6ICRGQIHYnU+VjkAoFeRNHMXkSTxBamcOa4GnuPrAwg+
D0CJeKYy2S9f1YsoWSQKL+TIz78UfmWua4eEDOaDeMFqtZPIH30qLw3RMiGu15yd
ToODavP3SZQXItYGuq15JSs+5rsm/I/D5V7GbCSVRdYj/u44sj38Oqz0p2zU/wd0
qsgZfo4PTDk38m26BJE1yq5R9uzW2/TdQX4k0UKNjl4tqwjrQ4zaRx3dQEWfec/B
vUdXjN4XJ3Ytmddvk2Qb1Drs70DZimhMS6DkGTYN3acrxVr0G+dub/F6vOxt6Nng
oN0LYzpJQ1oD7HImx1gNSFmfhiuhT51iO6qfAqJFik8KrD2PVBzDMXa8ShYggfry
mkf0EpRpP2n3DNBFGcfdv23PwzbByXrsXxopKNk73b5pbQ+WwWVfqao8Enl8/ASK
+KLV0UHgfGD+AcLte4kbJl+k6eVrUQsnBw8v//1EQYCxFG1vPUixV7UrR3eGKYBI
g07DiynqWDwetad8eYCMPOeKUBTXRfa57W/edvkHtOjLlqfaeUyfue4Jxx5yqvps
nbpMpuRf0T4bumJDcWJW4n6DibrhOi1uoCgdu/PzH1lFiWt6NnJEva4ovgGZ4O3Y
JisNcVJAcrs=
=fInv
-----END PGP SIGNATURE-----

Re: "Metas"

[The Amazing Dragon]

> From: Grant Miner <mine0057@mrs.umn.edu>
> > I don't think I've heard a single person, except Hans,
> > voice any support for "metas".
> 
> I like "metas".

Chalk me up as neutral about the name itself. That is I'm neutral about
".metas" or "..metas", I'm firmly against using "metas" (or any other
name) without at least a leading period. I suspect Linus et al might very
well reject such a FS because this would be a fatal flaw. I'm concerned
about using such a short and therefore precious name for filesystem
functions, but OTOH it might well be accessed often by a user and
therefore appropriate.

> > It seems that the most widely supported name thus far
> > is "...".

> Maybe "props" would be a good name?  It is short for properties, which 
> is synonymous with metadata and attributes (oops, I used a heretical 
> word! :)

Might ".properties", ".metadata" or ".attributes" work? Programs
shouldn't have a problem with a 12 character string occuring once in
their code. From a shell you'll be able to use filename completion, or
11 characters isn't that many to type. (and the leading dot avoids
breaking zillions of programs with security implications)


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \   (    |         EHeM@cs.pdx.edu      PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/

Re: "Metas"

[Narcoleptic Electron]

David Masover wrote: 

> As far as '...', since I haven't had an opinion yet
> -- I believe that a
> '...' would be nice, but the usage of '.' and '..'
> is so generic
> (current/parent dir) that we want to make sure '...'
> is just as generic
> and universally useful.  Otherwise, we may end up
> with things like
> '...................' in a few years.

Metadata is *more* fundamental than "." and "..",
because these latter concepts can be expressed as
metadata themselves (eg. one could implement "." and
".." as  ".../self" and ".../parent", respectively,
and maybe even ".../parents" for multiple parents).

> Also, I can't see ... as being any easier than
> ..metas (or, of course,
> .metas).  At the shell, it's typing "<dot> <dot>
> <dot>" instead of
> "<dot> m <tab>" or even "<dot> <dot> m <tab>". 

In order to save people from continuing to repeat
flawed arguments against "...", I would like to
attempt to summarize arguments for "..." that I have
seen thus far:

- ACCURATE LINGUISTIC MEANING.  In most, if not all,
written languages, an ellipsis ("...") means
"additional information"; in this case, additional
information about the directory.  Note that as an
ellipsis, dots do not represent "special characters";
the ellipsis is a linguistic construct, and natural
for non-technical users.

- ACCURATE UI MEANING.  Ellipsis is used universally
in GUIs to indicate the concept of "additional
information" (1), which applies here.

- ACCURATE *NIX MEANING.  Implies ".." (really hidden
system file) + "." (current directory): thus, taken
together,  "really hidden system stuff pertaining to
the current directory".  Taken together with the first
two points, this is _unbelievably_ elegant to me.

- VERY EASY TO TYPE (and easier than "metas", ".metas"
and "..metas").  Studies have conclusively shown (eg.
Fitts law) that the ease of an action increases
dramatically the less one's hand or fingers must be
moved to complete the action.  This means that
pressing the same key three times is easier than
pressing two different keys.  "metas" requires "m" and
"<tab>" at best (which are at opposite ends of the
keypad), and several character and/or tab key presses
at worst, depending on directory contents.  Since the
metadata directory will be fundamental and widely used
(hackers are users too!), this is an important
consideration.

- LESS LIKELY TO BE REJECTED BY LINUS.  The ellipsis
name uses the *nix convention of specifying a "really
hidden" system file with two dots.  This will prevent
name clashes with user files, and will be far more
likely to be accepted by the technical community --
most notably, Linus.

- NAME CLASHES WOULD BE A USABILITY DISASTER. 
Compounded by the fact that "metas" uses the *nix
naming convention for a user file (i.e. no leading
dots), it has been noted that "metas" means "goals" in
some languages.  Users that unpack an archive
containing a "metas" directory will not know where to
look for their data, even if there is a clever escape
plan (eg. "/nometas", "metas/escape", whatever).  They
may not even know what the problem is; just that "MY
FILES HAVE BEEN LOST!".  I can guarantee at least one
desperate email to this list on the subject, assuming
that the user is even able to determine that ReiserFS
is the culprit.  This is a disaster waiting to happen,
and this cannot be stressed enough.

- DEFAULTS MATTER!  In addition to the functionality
problems caused by a poor name choice (see previous
point), users will complain about it in review
articles, etc., before realizing (if ever) that it can
be changed.  This will be a black mark on Reiser4.

I beg for the patience of those that find this thread
tedious.  We all have different priorities; my top
priority on any project is usability.  I have seen too
many brilliant OSS projects hampered by heinous, and
easily avoided, usability mistakes.

Thanks,
N. Electron

(1) See the following pages for details:

"http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGText/chapter_12_section_3.html#TPXREF126"

"http://wiki.kdenews.org/tiki-index.php?page=KDE+Pseudo-HIG#id450424"

"http://developer.gnome.org/projects/gup/hig/1.0/menus.html#menu-item-types"

"http://www.palmos.com/dev/support/docs/uiguidelines.pdf"
(search for "ellipsis")


______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

Re: "Metas"

[Narcoleptic Electron]

David Masover wrote:

> As far as '...', since I haven't had an opinion yet
> -- I believe that a
> '...' would be nice, but the usage of '.' and '..'
> is so generic
> (current/parent dir) that we want to make sure '...'
> is just as generic
> and universally useful.  Otherwise, we may end up
> with things like
> '...................' in a few years.

Metadata is *more* fundamental than "." and "..",
because these latter concepts can be expressed as
metadata themselves (eg. one could implement "." and
".." as  ".../self" and ".../parent", respectively,
and maybe even ".../parents" for multiple parents).

> Also, I can't see ... as being any easier than
> ..metas (or, of course,
> .metas).  At the shell, it's typing "<dot> <dot>
> <dot>" instead of
> "<dot> m <tab>" or even "<dot> <dot> m <tab>". 

In order to save people from continuing to repeat
flawed arguments against "...", I would like to
attempt to summarize arguments for "..." that I have
seen thus far:

- ACCURATE LINGUISTIC MEANING.  In most, if not all,
written languages, an ellipsis ("...") means
"additional information"; in this case, additional
information about the directory.  Note that as an
ellipsis, dots do not represent "special characters";
the ellipsis is a linguistic construct, and natural
for non-technical users.

- ACCURATE UI MEANING.  Ellipsis is used universally
in GUIs to indicate the concept of "additional
information" (1), which applies here.

- ACCURATE *NIX MEANING.  Implies ".." (really hidden
system file) + "." (current directory): thus, taken
together,  "really hidden system stuff pertaining to
the current directory".  Taken together with the first
two points, this is _unbelievably_ elegant to me.

- VERY EASY TO TYPE (and easier than "metas", ".metas"
and "..metas").  Studies have conclusively shown (eg.
Fitts law) that the ease of an action increases
dramatically the less one's hand or fingers must be
moved to complete the action.  This means that
pressing the same key three times is easier than
pressing two different keys.  "metas" requires "m" and
"<tab>" at best (which are at opposite ends of the
keypad), and several character and/or tab key presses
at worst, depending on directory contents.  Since the
metadata directory will be fundamental and widely used
(hackers are users too!), this is an important
consideration.

- LESS LIKELY TO BE REJECTED BY LINUS.  The ellipsis
name uses the *nix convention of specifying a "really
hidden" system file with two dots.  This will prevent
name clashes with user files, and will be far more
likely to be accepted by the technical community --
most notably, Linus.

- NAME CLASHES WOULD BE A USABILITY DISASTER. 
Compounded by the fact that "metas" uses the *nix
naming convention for a user file (i.e. no leading
dots), it has been noted that "metas" means "goals" in
some languages.  Users that unpack an archive
containing a "metas" directory will not know where to
look for their data, even if there is a clever escape
plan (eg. "/nometas", "metas/escape", whatever).  They
may not even know what the problem is; just that "MY
FILES HAVE BEEN LOST!".  I can guarantee at least one
desperate email to this list on the subject, assuming
that the user is even able to determine that ReiserFS
is the culprit.  This is a disaster waiting to happen,
and this cannot be stressed enough.

- DEFAULTS MATTER!  In addition to the functionality
problems caused by a poor name choice (see previous
point), users will complain about it in review
articles, etc., before realizing (if ever) that it can
be changed.  This will be a black mark on Reiser4.

I beg for the patience of those that find this thread
tedious.  We all have different priorities; my top
priority on any project is usability.  I have seen too
many brilliant OSS projects hampered by heinous, and
easily avoided, usability mistakes.

Thanks,
N. Electron

(1) See the following pages for details:

"http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGText/chapter_12_section_3.html#TPXREF126"

"http://wiki.kdenews.org/tiki-index.php?page=KDE+Pseudo-HIG#id450424"

"http://developer.gnome.org/projects/gup/hig/1.0/menus.html#menu-item-types"

"http://www.palmos.com/dev/support/docs/uiguidelines.pdf"
(search for "ellipsis")


______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

Re: "Metas"

[Zygo Blaxell]

Jumping into a thread already in progress ;-)

Just for the record, if "..." is used for filesystem metadata, I
_will_ have to modify some software.  This modification will take
about 10 seconds to do (far less time than a Reiser4 conversion), but
it will have to be done nonetheless.  I used "..." because (at the
time) nobody else did.  :-P

In article <20040418033328.24278.qmail@web25006.mail.ukl.yahoo.com>,
Narcoleptic Electron  <narcoleptic_electron@yahoo.co.uk> wrote:
>David Masover wrote:
>
>- LESS LIKELY TO BE REJECTED BY LINUS.  

If you look through the archives you can see Linux responding to CVS
weenies who complained when Linus created directories named "core".
Apparently people who use CVS simply do not name their directories "core".

>- NAME CLASHES WOULD BE A USABILITY DISASTER. 

The more complicated the filename syntax and semantics, the more errors
might occur in user-space.  One of the nice things about most Unix
filesystems is that any conceivable null-terminated string is a valid
path through a DAG to an object of predictable type, subject to a few
length constraints.  Given a string, a user-space program can analyze
the string and infer filesystem structure from it, and the worst-case
difference between the user-space analysis and the kernel-space analysis
is that the string is not usable in the kernel because it is too long.

To understand why this is so nice, consider what happens on operating
systems where this is not true.  On Windows, a string with a particular
syntax is a valid path to a file or directory object...most of the
time.  If the last component of the string has a magic value, it may be
used as a key in a lookup table to a fatally different kind of object.
Windows filesystems have a veritable minefield of inconsistent, illegal,
or just plain surprising magic names.  Windows web servers used to have
all kinds of security problems (mostly DoS attacks) if the bad guys ask
the server for a URL with "con" or "com1" or "prn" or "lpt1" in the name.

A Unix server process needs only to know about symlinks, directories,
files, and "everything else" to be able to make useful access decisions.
The only significant character in a filename is the "/" and the only magic
file names are "." and "..", and the only exception to those two rules is
when the first character in the name is a "/".  All path searches end in
one of two things: an error, or an object with a particular file type.
The same server running on a filesystem that introduces a new special
file type (with a magic name no less) will have to be modified to control
access to the stuff with magic names.  If the server creates files then
it also has to control people who might create files with the magic
names too.

So a good question to ask is "What would happen if I ran Apache or an
FTP server with an incoming directory on top of this thing?" and if
the answer contains the phrase "you should put a few extra lines in
{access,srm}.conf to avoid having people surfing your metadata," then
you have a name clash.

Another thing to consider is that the namespace "names that begin with dot
and refer to metadata about nearby files" is very crowded by now.  If you
want to have some hidden files in a subdirectory that contained metadata,
you (and 50 other people) would logically consider the name ".meta".
I have seen a web server's example config files and a proprietary
cross-platform network file server which both used the name ".meta".

Perhaps the name should include the name of the filesystem which is
implementing the semantics, like ".reiser4meta"?  Presumably in the
fullness of time one might have to worry about versioning the metadata
too.  If the metadata is intended to be used across all Linux filesystems,
it would be called ".linuxmeta".

Or maybe...hmmm...

> $ echo $(tr -dc a-zA-Z0-9 < /dev/urandom | head -c6)
> 0fpjBC

A good name might be ".0fpjBC", which I'm pretty sure nobody has used
before.

>- DEFAULTS MATTER!  In addition to the functionality
>problems caused by a poor name choice (see previous
>point), users will complain about it in review
>articles, etc., before realizing (if ever) that it can
>be changed.  This will be a black mark on Reiser4.

I would suggest disabling the feature entirely until userspace supplies a
parameter with no default for the name.  The 'mount' command or whatever
program writes the option field in /etc/fstab might later be extended with
a default if there is widespread agreement on one.

Then again, maybe I'm too darn reactionary to like the idea at all.

-- 
Zygo Blaxell (Laptop) <zblaxell@feedme.hungrycats.org>
GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD

Re: "Metas"

[Hans Reiser]

so if rename works on metas, are you guys happy?  that is, if mv 
filename/metas filename/... works, are you less worried about the one in 
10 million users who will actually hit the reserved keyword?

RE: "Metas"

[Burnes, James]

Hans,

What could be the worst case if someone hits a file collision with the
reserved word?  Could reiser automagically detect the reserved word
conflict and correct it?

jb

jim burnes
security engineer
great-west, denver
 

> -----Original Message-----
> From: Hans Reiser [mailto:reiser@namesys.com]
> Sent: Wednesday, April 21, 2004 10:18 AM
> To: reiserfs-list@namesys.com
> Subject: Re: "Metas"
> 
> so if rename works on metas, are you guys happy?  that is, if mv
> filename/metas filename/... works, are you less worried about the one
in
> 10 million users who will actually hit the reserved keyword?

Re: "Metas"

[John D. Heintz]

How would we look up the current name of the "metas" pseudo directory? 
This affects tools (GUI, scripts) that would need to reliably find the 
"metas" pseudo directory regardless of renames.

If there is a good answer to this question I think I would be absolutely 
happy.

Thanks,
John D. Heintz


 >> -----Original Message-----
 >> From: Hans Reiser [mailto:reiser@namesys.com]
 >> Sent: Wednesday, April 21, 2004 10:18 AM
 >> To: reiserfs-list@namesys.com
 >> Subject: Re: "Metas"
 >>
 >> so if rename works on metas, are you guys happy?  that is, if mv
 >> filename/metas filename/... works, are you less worried about the one

in

 >> 10 million users who will actually hit the reserved keyword?

Re: "Metas"

[Hans Reiser]

So you want some sort of ....this_name_will_never_collide_with_anything 
that is a synonym for metas, so that metas can be renamed?

I don't think programmers will bother to code for it in their apps.  
Otherwise it would be okay with me.

Hans

John D. Heintz wrote:

> How would we look up the current name of the "metas" pseudo directory? 
> This affects tools (GUI, scripts) that would need to reliably find the 
> "metas" pseudo directory regardless of renames.
>
> If there is a good answer to this question I think I would be 
> absolutely happy.
>
> Thanks,
> John D. Heintz
>
>
> >> -----Original Message-----
> >> From: Hans Reiser [mailto:reiser@namesys.com]
> >> Sent: Wednesday, April 21, 2004 10:18 AM
> >> To: reiserfs-list@namesys.com
> >> Subject: Re: "Metas"
> >>
> >> so if rename works on metas, are you guys happy?  that is, if mv
> >> filename/metas filename/... works, are you less worried about the one
>
> in
>
> >> 10 million users who will actually hit the reserved keyword?
>
>
>

Re: "Metas"

[Grant Miner]

Hans Reiser wrote:

> so if rename works on metas, are you guys happy?  that is, if mv 
> filename/metas filename/... works, are you less worried about the one in 
> 10 million users who will actually hit the reserved keyword?
> 

That sounds like the best solution to the rare case where you would need 
to use a file named "metas".

But...what about the UNIX security issues where files that aren't 
executable can't have their "metas" accessed?  I suppose that will 
require extensive VFS changes and coordination with Al Viro?

Re: "Metas"

[John D. Heintz]

Yes, exactly.


Thanks,
John D. Heintz

Hans Reiser wrote:

> So you want some sort of ....this_name_will_never_collide_with_anything 
> that is a synonym for metas, so that metas can be renamed?
> 
> I don't think programmers will bother to code for it in their apps.  
> Otherwise it would be okay with me.
> 
> Hans
> 
> John D. Heintz wrote:
> 
>> How would we look up the current name of the "metas" pseudo directory? 
>> This affects tools (GUI, scripts) that would need to reliably find the 
>> "metas" pseudo directory regardless of renames.
>>
>> If there is a good answer to this question I think I would be 
>> absolutely happy.
>>
>> Thanks,
>> John D. Heintz
>>
>>
>> >> -----Original Message-----
>> >> From: Hans Reiser [mailto:reiser@namesys.com]
>> >> Sent: Wednesday, April 21, 2004 10:18 AM
>> >> To: reiserfs-list@namesys.com
>> >> Subject: Re: "Metas"
>> >>
>> >> so if rename works on metas, are you guys happy?  that is, if mv
>> >> filename/metas filename/... works, are you less worried about the one
>>
>> in
>>
>> >> 10 million users who will actually hit the reserved keyword?
>>
>>
>>
> 
> 
> 

Re: "Metas"

[mjt]

Hans Reiser wrote:

>so if rename works on metas, are you guys happy?

With all due respect:
You must be shitting me...

Lookups would be next to impossible, for one. And what if someone actually
loses a meta directory, like, renames it accidentally and forgets about it?
Yeah, far-fetched but stuff does happen...

What's so terribly bad about having the name for it in /proc or /sys
or wherever and having it global from the kernel config?

This is such a waste of time, really.

-- 
mjt

Re: "Metas"

[David Masover]

>
>What's so terribly bad about having the name for it in /proc or /sys
>or wherever and having it global from the kernel config?
>  
>
Imagine if I had to do
    cd `cat /sys/names/parent_directory`
instead of
    cd ..
Or even
    cd $parent_directory
or
    cd $parent

The fact is, for the usability to be sane in a text world, you're going 
to have to stomp on somebody's namespace.  If we were talking about 
scripts, it'd be different, but we're talking about something that I 
know I'd find a _manual_ use for.  Even if you say that I can set it to 
'...' myself, there's the problem of everyone having different 
definitions of that.  Imagine if, before I could even 'cd ..', I had to 
make sure that '..' was really '..'?  Or I might accidentally 'rm -rf 
../something' and have it mean something entirely different, because I'm 
on a different machine?

Note that in creating /proc/sys/names, I may have stomped on somebody 
anyway.  And here we have the chicken-and-egg thing of
    cd `cat /sys/\`/sys/names\``
and so on...

I vote for '...' if Hans/Linus/the Powers that Be will allow it.

>This is such a waste of time, really.
>  
>
Not really.  We already have 'metas' working, and now people want to 
change it.  There are a few choices here, if we wanted to "not waste time":
    Change it to the most popular idea, then change it again, and again, 
until people stop bickering.  They won't, and this is just confusing to 
users.
    Leave it the same until someone comes up with a generally accepted idea.
    Hans arbitrarily picks an idea.

Option #2 is what appears to be happening, and is the right thing to do 
-- make something that works (somewhat) so that other development may 
continue, then don't waste any more coding time on it until the design 
is solid.

Or, if you mean that bickering is a waste of time, get used to it -- 
we're human.  On top of that, if reiser4 is successful, no one may 
remember us, but they will use what we create here every day.

I appologize -- I shouldn't have said "we create".  I do little more 
than bicker.

Re: "Metas"

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

| But...what about the UNIX security issues where files that aren't
| executable can't have their "metas" accessed?  I suppose that will
| require extensive VFS changes and coordination with Al Viro?

I had an idea I was all ready to send in again, but it doesn't quite
work.  The idea was to make execute mean "execute", and have no meaning
for directories.  Rather, directories are either "readable" or "not
readable".

Another idea which seems to work much better is to merely have two modes
for each file -- one for the file-as-a-file and one for the
file-as-a-directory.  This could allow for files in which the file can
be read, but none of its children can.  By default, foo/ has the same
permissions as foo, but foo/ is guarenteed to have an execute bit when
foo is first created.  The problem is making this efficient -- for
almost all files, this would never be changed, but for some files, it
would, which suggests something like inheritance -- if a certain
property of a file does not exist, it is inherited from the parent, and
/ would have sane properties.

I like both ideas, because I think the execute bit on directories is
useless for everything except reiser4, but then I thought:  maybe foo is
a hash of foo/password, but foo/password is read/write, not just write,
so with reiser4, it makes sense to be able to read() but not readdir()
or chdir(), even if it still doesn't make sense to be able to
read/readdir but not chdir.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQItHK3gHNmZLgCUhAQIuPBAAne/dW0NJZsrz5O2nEUnswdka1tLGmtKq
j3u5qOu3mBJditsrUDBCzlA2OKEbn+lEjZAPzOxE/K3Ov/AiQuvV0VJdjscLoRhE
nBBqVXHbrf0xK0TIKm/J8IFY94ki/FkJ2Qnb7OnGfyldbTDhl9myl/E7jgPDjgNG
R1dkF3hfT8phDHwBEdPPAvU5f9stR8mRsk39DoIH6rwHdN3F35Nb15H6pzdWgd0C
uAsqwRqiX1TmGsbg6buTmXl3gfgf1fKEFpTZu6gE7CTrebtidc6S1vtIF2hQEdog
6JIHF40bI51cGV79ob0yebXfD3gxBeXKYUE97CCptQbHxJBsCkNrG1G9OHd6AINl
HifQnQg5bH/VieyygoANwZVyxWbpGsk/6t5Toz7mLB2eUZJgRe8uNvJhkWjg/SKI
NsMwGbKeXNNUkE3X8yJfhdeG2tKY1N95E4u8aE3EIwNYbqSiwhWqMzwVjCPE3Ueu
i6ZGVO7/Kmc+iPbFEKGmwGrbxEany7edAv33QoZfATMoGRTE5uBHsUkCWWl466B9
vCUMXR5UaL9DK8FANw7czZbcDwIqEw8S/IFeCOYEq1naQl7XsvBrunu0tC+9RKvs
XnMqxmDbroIizpA7lsEyeXZXO/Hg3H3vZCudqfbJbQajeT9P/1qvvJvA4VcNxFsP
sq1bYtpHJFE=
=Kmts
-----END PGP SIGNATURE-----

Re: "Metas"

[Hubert Chan]

>>>>> "David" == David Masover <ninja@slaphack.com> writes:

[...]

David> Another idea which seems to work much better is to merely have
David> two modes for each file -- one for the file-as-a-file and one for
David> the file-as-a-directory.  ...

This makes a lot of sense to me.  I like it.  I think that it's
reasonable to say that the desired permissions for a file as a file may
not necessarily be the same as the desired permissions for a file as a
directory.

I wonder if this would require more or less changes to the VFS compared
to creating a new permission for chdir.

-- 
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: "Metas"

[mjt]

On Sat, Apr 24, 2004 at 11:38:05PM -0500, David Masover wrote:

>Imagine if I had to do
>   cd `cat /sys/names/parent_directory`

You would not. It would simply be a means of accessing the name
of the parent directory.

If you were in a situation where you would not know the name of
the parent directory.

>scripts, it'd be different, but we're talking about something that I 
>know I'd find a _manual_ use for.  Even if you say that I can set it to 

You check it once to see if the kernel has the default names for
the metas directory. "Oh, bugger, it's changed to METAS, then I guess
I'll use cd METAS in the furure"

As for scripts it's easy to say `cat`

>definitions of that.  Imagine if, before I could even 'cd ..', I had to 
>make sure that '..' was really '..'?  Or I might accidentally 'rm -rf 
>../something' and have it mean something entirely different, because I'm 
>on a different machine?

I think this is a gross exaggeration ;)

>I vote for '...' if Hans/Linus/the Powers that Be will allow it.

I'm still sticking to ..metas/ and I don't know why I even touched
a thread like this :)

>Not really.  We already have 'metas' working, and now people want to 
>change it.  There are a few choices here, if we wanted to "not waste time":

Discussing the point per se is not a waste of time, it's the bickering.

This is starting to look like a stalemate Debian vs Gentoo war :)

>   Change it to the most popular idea, then change it again, and again, 
>until people stop bickering.  They won't, and this is just confusing to 
>users.

Or every administrator decides on what they'll have on their machines.

>   Leave it the same until someone comes up with a generally accepted idea.

Which is just as easily circumvented by one like of kernel code.

>   Hans arbitrarily picks an idea.

He already did.

>Option #2 is what appears to be happening, and is the right thing to do 
>-- make something that works (somewhat) so that other development may 
>continue, then don't waste any more coding time on it until the design 
>is solid.

This is pretty true. I certainly hope the Namesys people are semi-ignoring
this thread for better work on something more important.

>Or, if you mean that bickering is a waste of time, get used to it -- 
>we're human.  On top of that, if reiser4 is successful, no one may 
>remember us, but they will use what we create here every day.

I just want to see this thing fly, get into distros, gain popularity,
be the best fscking (pun intended) file system around :)

That includes standing behind ..metas/, a /sys/ export and a kernel
macro or whatever means that an admin can use to semi-trivially change
the system's name for the dir.

And never have mv work on the directory, especially while it's invisible
to readdir.

-- 
mjt

Re: "Metas"

[Valdis.Kletnieks]

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

On Sun, 25 Apr 2004 13:09:26 +0300, Markus =?UNKNOWN?Q?T=F6rnqvist?= said:
> On Sat, Apr 24, 2004 at 11:38:05PM -0500, David Masover wrote:

> >scripts, it'd be different, but we're talking about something that I 
> >know I'd find a _manual_ use for.  Even if you say that I can set it to 
> 
> You check it once to see if the kernel has the default names for
> the metas directory. "Oh, bugger, it's changed to METAS, then I guess
> I'll use cd METAS in the furure"
> 
> As for scripts it's easy to say `cat`

For bonus points, try writing a bash script fragment that will Do The Right Thing
whether or not the file system in question is Reiser4.

It really sucks when your script does:

cd `cat /sys/names/parent_directory`

only to have it bomb out because cat can't open it.

It sucks even worse if it actually *works* because some b0rked script
had previously done:

mkdir `cat /sys/names/parent_directory`

Don't believe me? I've seen plenty of scripts that will do an 'rm $foo'
where $foo is a parameter passed - so somebody runs the script with

/usr/local/bin/foo -o /dev/null

and later on you're trying to figure out why /dev/null is a 49 megabyte
regular file.. ;)

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

Re: "Metas"

[The Amazing Dragon]

> From: Hans Reiser <reiser@namesys.com>
> so if rename works on metas, are you guys happy?  that is, if mv 
> filename/metas filename/... works, are you less worried about the one in 
> 10 million users who will actually hit the reserved keyword?

I think we've provided evidence that it might well be one in one
thousand. Pretty much any filename that `ls` without the "-a" option
will display will be unacceptable. Adding a leading '.' or using a
separator character ('\' or "/.metas/" perhaps) fits this qualification.

> From: mjt@nysv.org (Markus Törnqvist)
> Lookups would be next to impossible, for one. And what if someone actually
> loses a meta directory, like, renames it accidentally and forgets about it?
> Yeah, far-fetched but stuff does happen...

I don't think this is at all far fetched, Hans, please listen!

> What's so terribly bad about having the name for it in /proc or /sys
> or wherever and having it global from the kernel config?

open()/read()/write()/stat()/readdir() are system calls, but fairly cheap
operations. getcwd() is a library call, almost certainly making
*hundreds* of system calls, and quite possibly *thousands*. In order to
use a /proc or /sys interface you'd need to use getcwd(), if you're
accessing many files this would be extremely expensive.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \   (    |         EHeM@cs.pdx.edu      PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/

Re: "Metas"

[Hubert Chan]

>>>>> "Elliot" == The Amazing Dragon (Elliott Mitchell) <ehem@cs.pdx.edu> writes:

[...]

Elliot> I think we've provided evidence that it might well be one in one
Elliot> thousand. Pretty much any filename that `ls` without the "-a"
Elliot> option will display will be unacceptable.

metas is not returned by readdir(), so won't show up in ls.
Nevertheless, I'm still in favour of adding a leading dot (or two).  I
don't think that allowing renames is a good idea, especially given that
the metas directory is not returned by readdir -- the user (or
application) has no way of discovering what the name is.

>> From: mjt@nysv.org (Markus Törnqvist)

>> What's so terribly bad about having the name for it in /proc or /sys
>> or wherever and having it global from the kernel config?

Elliot> open()/read()/write()/stat()/readdir() are system calls, but
Elliot> fairly cheap operations. getcwd() is a library call, almost
Elliot> certainly making *hundreds* of system calls, and quite possibly
Elliot> *thousands*. In order to use a /proc or /sys interface you'd
Elliot> need to use getcwd(), if you're accessing many files this would
Elliot> be extremely expensive.

I don't see why putting the name in /proc or /sys requires getcwd().
Can you explain in more detail?

Oh.  I think you're talking about something different from what Markus
is talking about.  I think you're talking about putting metadata for
/foo/bar into, say, /proc/metas/foo/bar.  What Markus is talking about
is having a file called, say /proc/fs/reiser4/metas, and if you cat
that file, it will spit out the name of the metas directory.

I don't like it because I think that Reiser4 should be consistent.
Making users look up the name from /proc/fs/reiser4/metas I think is a
lot worse than making them use a long name for the metas directory.  And
"ls foo/`cat /proc/fs/reiser4/metas`", or even "ls foo/$metas", where
$metas is the cached value of /proc/fs/reiser4/metas, is a lot uglier
than "ls foo/.metas".

Yet another option is to standardize on a long, extremely unlikely to
clash name as the standard way to access the metadata (maybe something
like "sys.metadata"), and define a short name, which is probably defined
at compile time, which can be looked up through something like
/proc/fs/reiser4/metas_abbrev.  That way, users (and scripts) get a
consistent interface, but if they want to save typing, they can look up
the short name.

-- 
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: "Metas"

[mjt]

On Wed, Apr 28, 2004 at 02:49:12AM -0400, Hubert Chan wrote:
>/foo/bar into, say, /proc/metas/foo/bar.  What Markus is talking about
>is having a file called, say /proc/fs/reiser4/metas, and if you cat
>that file, it will spit out the name of the metas directory.

Yes, were it for the current directory (/sys always changing its contents)
or one global name.

The current directory mv-supporting thing is like death itself and should
not be implemented. Nor should mv support be implemented without sys
support because then people may forget their metadata directory name
without any chance of looking it up, except for maybe something in debugfs
or somewhere, which is not implemented afaik.

Consider how much work this would be due to bickering.

>I don't like it because I think that Reiser4 should be consistent.

I agree.

>Making users look up the name from /proc/fs/reiser4/metas I think is a
>lot worse than making them use a long name for the metas directory.  And

Mmmmyeah, but I don't think having the directory name exported in 
something like that is a bad idea per-se, as long as it exports a
global, static name. If we have a situation where different people
use different names. Which will happen if we have a clashing ./metas/
directory.

>Yet another option is to standardize on a long, extremely unlikely to
>clash name as the standard way to access the metadata (maybe something
>like "sys.metadata"), and define a short name, which is probably defined
>at compile time, which can be looked up through something like
>/proc/fs/reiser4/metas_abbrev.  That way, users (and scripts) get a
>consistent interface, but if they want to save typing, they can look up
>the short name.

And the abbreviation would never conflict, because when a process tries
to write to the abbreviated name, the file system realizes this and
goes "oh shit, I must make way to tar xf, *poof*"?

Incredible amounts of work again in vain.

Besides, length has little to do with it. Consider ..metas. It's not
long but what are the odds of accidental clashing?

Just my two cents, which I seem to contribute over and over again ;)

-- 
mjt