[PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Piotr Neuman]

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

The new naming scheme for plugins ("metas" in snapshot 2004.03.26) may on 
certain occasions cause name clashes. This patch changes "metas" into 
"..metas" which should avoid this problem in most cases.

This is a very simple patch so changing "..metas" that to any other desired 
value is also easy.

Regards to reiser4 team.

diff -ruN /home/peter/linux/fs/reiser4/plugin/pseudo/pseudo.c 
linux/fs/reiser4/plugin/pseudo/pseudo.c
--- /home/peter/linux/fs/reiser4/plugin/pseudo/pseudo.c	2004-03-27 
14:50:58.000000000 +0100
+++ linux/fs/reiser4/plugin/pseudo/pseudo.c	2004-03-27 14:51:19.788181928 
+0100
@@ -1224,7 +1224,7 @@
 			.type_id = REISER4_PSEUDO_PLUGIN_TYPE,
 			.id = PSEUDO_METAS_ID,
 			.pops = NULL,
-			.label = "metas",
+			.label = "..metas",
 			.desc = "meta-files",
 			.linkage = TYPE_SAFE_LIST_LINK_ZERO
 		},

[-- Attachment #2: reiser4.metas.patch --]
[-- Type: text/x-diff, Size: 502 bytes --]

diff -ruN /home/peter/linux/fs/reiser4/plugin/pseudo/pseudo.c linux/fs/reiser4/plugin/pseudo/pseudo.c
--- /home/peter/linux/fs/reiser4/plugin/pseudo/pseudo.c	2004-03-27 14:50:58.000000000 +0100
+++ linux/fs/reiser4/plugin/pseudo/pseudo.c	2004-03-27 14:51:19.788181928 +0100
@@ -1224,7 +1224,7 @@
 			.type_id = REISER4_PSEUDO_PLUGIN_TYPE,
 			.id = PSEUDO_METAS_ID,
 			.pops = NULL,
-			.label = "metas",
+			.label = "..metas",
 			.desc = "meta-files",
 			.linkage = TYPE_SAFE_LIST_LINK_ZERO
 		},

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hans Reiser]

Piotr Neuman wrote:

>The new naming scheme for plugins ("metas" in snapshot 2004.03.26) may on 
>certain occasions cause name clashes. This patch changes "metas" into 
>"..metas" which should avoid this problem in most cases.
>
>  
>
The name clashing is less important than the greater user friendliness.  
Users on the mailing list convinced me of this.

-- 
Hans

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Filipe Almeida]

On Sunday 28 March 2004 17:40, Hans Reiser wrote:
> Piotr Neuman wrote:
> >The new naming scheme for plugins ("metas" in snapshot 2004.03.26) may on
> >certain occasions cause name clashes. This patch changes "metas" into
> >"..metas" which should avoid this problem in most cases.
>
> The name clashing is less important than the greater user friendliness.
> Users on the mailing list convinced me of this.

Isn't this is introducing the kind of side effects that existed in windows 
machines with the "con" and "aux" special filenames?
IMHO, it doesn't seem wise to introduce a special filename called metas into 
unix. Something prefixed with a special character like ... would be much 
safer.

About the user user friendliness issue, would novice users be messing with the 
metadata exposed by reiser4 pseudo files? I think this will be a feature for 
software and advanced users.

Regards,
Filipe Almeida 

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hubert Chan]

>>>>> "Filipe" == Filipe Almeida <filipe@rnl.ist.utl.pt> writes:

[...]

Filipe> About the user user friendliness issue, would novice users be
Filipe> messing with the metadata exposed by reiser4 pseudo files? I
Filipe> think this will be a feature for software and advanced users.

I agree.  I think that metas should be prefixed with at least a
period (i.e. .metas).  There is enough precedent for dot-files that it
shouldn't be too much of a user-friendliness issue.  Actually, I would
argue that using a prefix would be more user-friendly, since it
indicates that metas is not a standard directory, and would lead to less
confusion.

Also, in terms of adoption of Reiser4, it's the techies who pick the
filesystem, not the users, and my feeling is that techies wouldn't like
just plain "metas" with no prefix.

-- 
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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Narcoleptic Electron]

Filipe Almeida wrote:

> On Sunday 28 March 2004 17:40, Hans Reiser wrote:
> > Piotr Neuman wrote:
> > >The new naming scheme for plugins ("metas" in
> snapshot 2004.03.26) may on
> > >certain occasions cause name clashes. This patch
> changes "metas" into
> > >"..metas" which should avoid this problem in most
> cases.
> >
> > The name clashing is less important than the
> greater user friendliness.
> > Users on the mailing list convinced me of this.
> 
> Isn't this is introducing the kind of side effects
> that existed in windows 
> machines with the "con" and "aux" special filenames?
> IMHO, it doesn't seem wise to introduce a special
> filename called metas into 
> unix.

I agree 100% (at least!).  As a user, I strongly
dislike  systems that impose unnecessary rules on me
(eg. don't allow me to name my file "metas", or
"..<whatever>").  There is no question that ReiserFS
is brilliant; it provides a unified, clean,
user-friendly namespace.  This is why sullying that
namespace with special exceptions is, in my opinion,
"clutching defeat from the jaws of victory".

Again, I point to my original idea of corralling _all_
"meta" files (MIME type, etc.) into a more
specially-named, non-localized directory ("+" or
somesuch).  Inside that directory, they can be named
anything, without dot prefixes or whatever.  There is
a thread here somewhere about this... it contains the
full rationale.

As far as user friendliness goes: the less rules the
user has to remember, the better.  Thus, the more
"special directories" there are, the less user
friendly the namespace is.  My recommendation to have
only one special directory, given an easy-to-remember
name, is the most user friendly option.

I will be happy to implement my special directory
idea, but I haven't had the time to do the requisite
background work yet (sorry...).

> About the user user friendliness issue, would novice
> users be messing with the 
> metadata exposed by reiser4 pseudo files? I think
> this will be a feature for 
> software and advanced users.

The namespace is sullied for all users, regardless of
whether they go inside the "metas" directory.


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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Claudio Martins]

On Sunday 28 March 2004 17:40, Hans Reiser wrote:
> Piotr Neuman wrote:
> >The new naming scheme for plugins ("metas" in snapshot 2004.03.26) may on
> >certain occasions cause name clashes. This patch changes "metas" into
> >"..metas" which should avoid this problem in most cases.
>
> The name clashing is less important than the greater user friendliness.
> Users on the mailing list convinced me of this.

  Please note that the supposed "user friendliness" you gain will go away the 
moment a user tries to unpack a source tarball for some project which happens 
to contain a directory named "metas". How are you going to fix it? You'll 
have the trouble of not getting the content of the "metas" directory which 
was inside the tarball and which tar failed to write to the directory, and 
you won't be able to build your project unless you modify it. This is just 
one example of many...

  So IMO it is much better to have a "..metas" and prevent all the trouble you 
*will* get for sure if using "metas".

  After all, unix filesystems have always been nice because they don't impose 
much restrictions on user filenames. As Filipe Almeida pointed out, why now 
reproduce the mess that exists in Windows with "aux" and such other special 
filenames?

Claudio

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hans Reiser]

Network appliance (.snapshot) and clearcase have demonstrated that 
having a few keywords reserved in the namespace is not a problem.

-- 
Hans

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Narcoleptic Electron]

Hans Reiser wrote: 

> Network appliance (.snapshot) and clearcase have
> demonstrated that 
> having a few keywords reserved in the namespace is
> not a problem.

Sure, and having a separate attribute namespace is not
a problem, and treating files and directories as
separate entities is not a problem... many other file
systems do these things successfully!  ;-)

My point is: even if it weren't a problem, it is not
elegant or user friendly.  It introduces an
unnecessary restriction on users (can't name your file
"metas"), and thus reduces usability by definition. 
This would be especially tragic, as ReiserFS is
otherwise such an elegant, brilliant and innovative
system.



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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Grant Miner]

Someone mentioned earlier, and I like just the at sign: @ Think of it 
short for "attributes".

file/@/uid

The nice thing about @ is it shows up early lexicographically, it's 
short and unlikely to be used.  This name is important to pick well 
because it will likely set a long precedent.

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Narcoleptic Electron]

Grant Miner wrote:

> Someone mentioned earlier, and I like just the at
> sign: @ Think of it 
> short for "attributes".
> 
> file/@/uid
> 
> The nice thing about @ is it shows up early
> lexicographically, it's 
> short and unlikely to be used.

I like it.  XSL also uses this symbol re: XML
attributes.  Other benefits:
- Doesn't need to be translated.
- Available on all int'l keyboards.
- Easy to remember.
- Less likely to cause name clash than a word.

Another favourite in that big thread we had on this
subject was "+" for the same reasons.  Either would be
more than fine with me, although I lean away from "@"
because the mnemonic only makes sense in English,
whereas "+" can mean "additional info" in any
language.

> This name is
> important to pick well 
> because it will likely set a long precedent. 

Absolutely.

What would be involved in making this type of change? 
(No time to get familiar with Reiser4 code yet...)


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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Valdis.Kletnieks]

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

On Mon, 29 Mar 2004 14:24:17 CST, Grant Miner <mine0057@mrs.umn.edu>  said:
> Someone mentioned earlier, and I like just the at sign: @ Think of it 
> short for "attributes".
> 
> file/@/uid
> 
> The nice thing about @ is it shows up early lexicographically, it's 
> short and unlikely to be used.  This name is important to pick well 
> because it will likely set a long precedent.

Don't use the MH mail handler on that filesystem then.  It uses a
symlink called '@' to point to "the current mail item". For instance, this
reply:

$ ls -l ~/@
1 lrwxrwxrwx  1 valdis valdis 28 Mar 29 20:30 /home/valdis/@ -> /home/valdis/Mail/reiser/849


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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Scott Young]

On Mon, 2004-03-29 at 15:53, Narcoleptic Electron wrote:

> > This name is
> > important to pick well 
> > because it will likely set a long precedent. 
> 
> Absolutely.


Regular can be accessed as directories to access their attributes, so
there is no name collision there.  Files can be accessed as directories
by putting a / at the end of their name.  Folders are more complicated,
but I think it should be done by just adding a slash after the full
directory name (full as in including a trailing slash, so therefore
there would be two slashes at the end to access an attribute). 
/home//attribute would be the an attribute on the home directory. 
However, this leaves an inconsistency between accessing attributes
between file types.  If given /some/path, do I put 1 or 2 slashes after
it to access the attribute?  This could lead to potential security
problems with a file being replaced with a directory with fake file
attributes.  Therefore, I think the double-slash should also be used for
regular files.  For example:  /etc/.passwd//attribute

Could ..metas be renamed to a null string to get this effect on
directories?

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[mjt]

Scott Young wrote:

>/home//attribute would be the an attribute on the home directory. 
...
>Could ..metas be renamed to a null string to get this effect on
>directories?

This sounds like the way it used to be, before the metas/ directory.
Please also note that it's metas/ officially now, not ..metas/

..metas/ is through Piotr Neuman's patch, which has gained some
popularity, but it's not official yet.

I think a double slash is a terrible idea. They are, probably by some
standard, interpreted as a single one in most cases.
As good as Reiser4 already is, it also poses threats to standards
and even some solid security issues with reserving names from the
filesystem.[1]

One concise directory is definitely the best way and I still stand
behind ..metas/ because it's most likely not to be clashed. Some
already pointed out problems with @ and .metas and such.

It's not good to think about lexicographic ordering, btw, because
readdir must not find this directory. Consider the following
times a million when taking a backup:
mjt@shrike:~/..metas/plugin/crypto/..metas/plugin/crypto/..metas$

[1]
Will there be a plugin suitable for for example html documentroots,
that disables the meta directory from its children?
It is unfair, to say the least, to have future users rewrite their
stupid php upload scripts, and every writing script for that matter,
to check that they don't conflict with metas.

It is also a good idea to implement a plugin like this if many people
will take up the habit of renaming their metas/ directories; one
server may have it by another name and that breaks hard-coded checks
in server software.

-- 
mjt

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Christian Mayrhuber]

What about introducing an separator for meta information, like
it is / for directories.
This separator could be turned into a mount option to avoid
breakage of some apps.

My suggestion is "@" to become the default separator, because XPath uses
it for attributes and it is THE accepted standard so far.
Filesystems are just a new domain.

On Tuesday 30 March 2004 14:35, Markus TXrnqvist wrote:
> Scott Young wrote:
> >/home//attribute would be the an attribute on the home directory.
"/home@attribute" would be my favour notion in this regard.
A listing of all attributes could be obtained by the notion "/home@*"

I'm not sure if this naming clashes with the reiser4
"A directory is a file" notion.
It won't clash if it is impossible to have
# ls -l 
drwxr-xr-x   11 foo     foo           712 2004-01-21 14:45 bla
-rw-r--r--   11 foo     foo           712 2004-01-21 14:45 bla
on reiser4.

>
> One concise directory is definitely the best way and I still stand
> behind ..metas/ because it's most likely not to be clashed. Some
> already pointed out problems with @ and .metas and such.
the clash of "@" does only occur if the notion is "/home/@", but not
with "/home@".
With the separator being a mount option, this can be turned into 
a non issue.
The separator must turn into an illegal char for filenames, which is not
too limiting, I guess.

> It's not good to think about lexicographic ordering, btw, because
> readdir must not find this directory. Consider the following
> times a million when taking a backup:
> mjt@shrike:~/..metas/plugin/crypto/..metas/plugin/crypto/..metas$
readdir must not see names with are denoted as meta information.

With the @ separator access to plugin/crypto/ would turn into
mjt@shrike:~@plugin/crypto/

PS: I don't know if the introduction of a new separator for meta information 
breaks the vfs standard in any way.

-- 
lg, Chris

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[mjt]

Christian Mayrhuber wrote:

>What about introducing an separator for meta information, like
>it is / for directories.

This is per se not a bad idea, imo.

>This separator could be turned into a mount option to avoid
>breakage of some apps.

I dislike mount options, but it may be worth a thought.

We talked on IRC about having a dynamic name for the metas/ directory,
possibly defined in make config, possibly controlled via sysfs and
many other alternatives. Also that it could be used through a read-only
envirinonment variable set by the kernel.

Nikita Danilov shot this idea down and I'm glad he did, although it
was my idea, because it smells like a kludge.

>With the @ separator access to plugin/crypto/ would turn into
>mjt@shrike:~@plugin/crypto/

I think this is not bad, but what would be the way to see the
contents of @? would it be
mjt@shrike:~$ ls @
bmap  items  locality  nlink  pagecache  pseudo   rwx   uid
gid   key    new       oid    plugin     readdir  size
or something?

But we must think rationally. What are the odds that the guys at
Namesys will induce any changes to the naming scheme being this
close to releasing?
How many man-hours would this take, seeing that it does not break
VFS or anything?

We already have one system for this which is, in all honesty,
in my opinion at least, good.
It just needs two things, made secure for servers without rewriting
userland software, that is, making sure no-one gets unwarranted
write access to pseudofiles AND having a non-offensive name.

I wouldn't stand against having @ as a separator, necessarily,
but it isn't my choice and I think we can be satisfied with what
we have. Even if it takes manually adding two dots to one line of code ;)

-- 
mjt

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Narcoleptic Electron]

Markus Törnqvist wrote: 

> Scott Young wrote:
> 
> >/home//attribute would be the an attribute on the
> >home directory. 
> 
> I think a double slash is a terrible idea. They are,
> probably by some
> standard, interpreted as a single one in most cases.

Can you footnote this one?  I would hate to eschew an
idea simply as a result of speculation.


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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Nikita Danilov]

Narcoleptic Electron writes:
 > Markus Törnqvist wrote: 
 > 
 > > Scott Young wrote:
 > > 
 > > >/home//attribute would be the an attribute on the
 > > >home directory. 
 > > 
 > > I think a double slash is a terrible idea. They are,
 > > probably by some
 > > standard, interpreted as a single one in most cases.
 > 
 > Can you footnote this one?  I would hate to eschew an
 > idea simply as a result of speculation.
 > 

----------------------------------------------------------------------
Pathname

A character string that is used to identify a file. In the context of
IEEE Std 1003.1-2001, a pathname consists of, at most, {PATH_MAX} bytes,
including the terminating null byte. It has an optional beginning slash,
followed by zero or more filenames separated by slashes. A pathname may
optionally contain one or more trailing slashes. Multiple successive
slashes are considered to be the same as one slash.

[The Open Group Base Specifications Issue 6]
----------------------------------------------------------------------

And... Google is your friend. :)

Nikita.

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Narcoleptic Electron]

Narcoleptic Electron wrote: 

> Again, I point to my original idea of corralling
> _all_
> "meta" files (MIME type, etc.) into a ... directory 

It seems that I misunderstood... I thought "..metas"
was just another meta file; I didn't realize that it
actually is the incarnation of my "special meta
directory" idea, which contains the meta files for the
parent.  Sorry for the noise.

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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hans Reiser]

I think that metas/ should be defined as a macro, and users should feel 
free to change it and recompile as suits their needs.

-- 
Hans

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hubert Chan]

>>>>> "Markus" == Markus Törnqvist <mjt@nysv.org> writes:

[...]

Markus> It's not good to think about lexicographic ordering, btw,
Markus> because readdir must not find this directory. Consider the
Markus> following times a million when taking a backup:
Markus> mjt@shrike:~/..metas/plugin/crypto/..metas/plugin/crypto/..metas$

pseudofiles shouldn't have metadata, so
~/..metas/plugin/crypto/..metas/plugin/crypto/... shouldn't exist
anyways.  But readdir shouldn't return that directory, because it's
just duplicated data.

-- 
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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hubert Chan]

>>>>> "Christian" == Christian Mayrhuber <christian.mayrhuber@gmx.net> writes:

Christian> What about introducing an separator for meta information,
Christian> like it is / for directories.  This separator could be turned
Christian> into a mount option to avoid breakage of some apps.

Christian> My suggestion is "@" to become the default separator, because
Christian> XPath uses it for attributes and it is THE accepted standard
Christian> so far.  Filesystems are just a new domain. ...

That effectively kills all filenames that contain @, much worse than
just a "metas" conflict IMHO.

-- 
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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hubert Chan]

>>>>> "Hans" == Hans Reiser <reiser@namesys.com> writes:

Hans> I think that metas/ should be defined as a macro, and users should
Hans> feel free to change it and recompile as suits their needs.

I had though about maybe making it a mount option, I don't really like
the idea, as it can induce confusion.  You can't just sit in front of
any Linux computer that uses Reiser4, and know how to easily access the
pseudofiles.  It may also confuse script writers.  I think it's best to
try to pick a sensible default that is the least likely to have people
up in arms.

P.S.  I really do think you guys are doing a great job, and look
forward to giving it a test run soon.

-- 
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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[The Amazing Dragon]

> From: Hubert Chan <hubert@uhoreg.ca>
> 
> >>>>> "Christian" == Christian Mayrhuber <christian.mayrhuber@gmx.net> writes:
> 
> Christian> What about introducing an separator for meta information,
> Christian> like it is / for directories.  This separator could be turned
> Christian> into a mount option to avoid breakage of some apps.
> 
> Christian> My suggestion is "@" to become the default separator, because
> Christian> XPath uses it for attributes and it is THE accepted standard
> Christian> so far.  Filesystems are just a new domain. ...
> 
> That effectively kills all filenames that contain @, much worse than
> just a "metas" conflict IMHO.

Which draws the question of which is worse to lose/more important to
preserve?

One possibility would be to use a character shells tend to grab and are
therefore extremely uncommon in filenames. The ones that come to mind
are ! & and \, perhaps it is a matter of tweaking the EvilOS folks, but
\ seems like a viable option. Failing that, I suspect & is also a
reasonable option as well.


-- 
(\___(\___(\______          --=> 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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hubert Chan]

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

[...]

Elliott> One possibility would be to use a character shells tend to grab
Elliott> and are therefore extremely uncommon in filenames. The ones
Elliott> that come to mind are ! & and \, perhaps it is a matter of
Elliott> tweaking the EvilOS folks, but \ seems like a viable
Elliott> option. Failing that, I suspect & is also a reasonable option
Elliott> as well.

But if the shell grabs it, that makes it even more painful to access.
We might as well just use ..metas, which is very unlikely to conflict.
Also, those uncommon characters you mention (except probably \) won't
be that uncommon, especially with GUIs becoming a more common
file-management method, and Linux being more accessible to
non-techies.  Heck, even *I've* named some files with *spaces* in the
name!  And I've been capitalizing some filenames!

(\ is probably a reasonable suggestion, though.  But I still prefer
..metas.  For one thing, adding another delimiter may cause confusion --
more rules for a user to learn, and would probably involve VFS changes,
which I doubt would be accepted.  Plus, I think that having mixed
forward-slashes and back-slashes in a path name would look ugly.)

-- 
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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[The Amazing Dragon]

> From: Hubert Chan <hubert@uhoreg.ca>
> 
> >>>>> "The" == The Amazing Dragon (Elliott Mitchell) <ehem@cs.pdx.edu> writes:
> 
> Elliott> One possibility would be to use a character shells tend to grab
> Elliott> and are therefore extremely uncommon in filenames. The ones
> Elliott> that come to mind are ! & and \, perhaps it is a matter of
> Elliott> tweaking the EvilOS folks, but \ seems like a viable
> Elliott> option. Failing that, I suspect & is also a reasonable option
> Elliott> as well.
> 
> But if the shell grabs it, that makes it even more painful to access.
> We might as well just use ..metas, which is very unlikely to conflict.
> Also, those uncommon characters you mention (except probably \) won't
> be that uncommon, especially with GUIs becoming a more common
> file-management method, and Linux being more accessible to
> non-techies.  Heck, even *I've* named some files with *spaces* in the
> name!  And I've been capitalizing some filenames!

But how often do you need to access meta information directly from a
shell? Most of the time it would be a GUI tool accessing the extra data,
do you normally need to use `file` before doing anything? Most of the
time you know that a file called "Pokemon" is something you're not going
to access with `vi`, so would you need the filetype meta data before
dealing with it?

Though you do have a point that the GUI tools filenames with '&' or '!'
becomes more common. '\' does have the advantage of simply needing to by
typed twice (rather than one key followed by shift-number combo). Useful
if you need to tell the tell the GUI what the file actually is.


-- 
(\___(\___(\______          --=> 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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Jonathan Briggs]

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

On Tue, 2004-03-30 at 23:20, The Amazing Dragon wrote:
[snip]
> But how often do you need to access meta information directly from a
> shell? Most of the time it would be a GUI tool accessing the extra data,
> do you normally need to use `file` before doing anything? Most of the
> time you know that a file called "Pokemon" is something you're not going
> to access with `vi`, so would you need the filetype meta data before
> dealing with it?

No, no, don't use that argument.  If you go there, we might as well go
back to using weird little ioctl/setattr/chacl calls.  I much prefer a
nice filesystem interface and it should be very easy to use from the
shell.
-- 
Jonathan Briggs <jbriggs@esoft.com>
eSoft, Inc.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Christian Mayrhuber]

On Wednesday 31 March 2004 04:50, Hubert Chan wrote:
> >>>>> "Christian" == Christian Mayrhuber <christian.mayrhuber@gmx.net>
> >>>>> writes:
>
> Christian> What about introducing an separator for meta information,
> Christian> like it is / for directories.  This separator could be turned
> Christian> into a mount option to avoid breakage of some apps.
>
> Christian> My suggestion is "@" to become the default separator, because
> Christian> XPath uses it for attributes and it is THE accepted standard
> Christian> so far.  Filesystems are just a new domain. ...
>
> That effectively kills all filenames that contain @, much worse than
> just a "metas" conflict IMHO.

Well, that's a matter of taste.
The most important thing is that once there is an access pattern to meta
information it is the same for all filesystems on Linux.

-- 
lg, Chris

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[mjt]

Elliot Mitchell wrote:

>But how often do you need to access meta information directly from a
>shell? Most of the time it would be a GUI tool accessing the extra data,
>do you normally need to use `file` before doing anything?

Assumptions are bad things. If I understood this correctly, in my
caffeine-depraved just-woken-up state.
(So I'm making an assumption too ;)

It seems a GUY tool accessing the extra data is way off in the future.
I might write some pyglade toy for this some day, but in general I
don't use GUI software. I know many others who don't either.

So the shell is the way to go.

On a sort-of other note:
I'm not sure either what Hans Reiser meant by a macro, does that mean
a settable variable? It's a decent compromise, I think. As someone
else stated, let's just hope for an inoffensive default.

-- 
mjt

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[mjt]

Christian Mayrhuber wrote:

>The most important thing is that once there is an access pattern to meta
>information it is the same for all filesystems on Linux.

Next to impossible to implement probably. How many filesystems have
accessible metadata at the moment?

Besides, in different filesystems the metadata layout will probably
vary, even more than in Reiser4 with its plugin architecture.

However, it would be GREAT if Reiser4 defined a standard here, because
the current layout is poetically beautiful.

-- 
mjt

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Christian Mayrhuber]

On Wednesday 31 March 2004 10:43, Markus TXrnqvist wrote:

> I'm not sure either what Hans Reiser meant by a macro, does that mean
> a settable variable? It's a decent compromise, I think. As someone
> else stated, let's just hope for an inoffensive default.

Yes, you can see a C macro as a compile time variable settable in the source 
code.

The evaluation result of a macro is copied to the caller's location during 
compile.

You can use macros to define some default values or to prevent code 
duplication and the overhead of a function call.

-- 
lg, Chris

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Narcoleptic Electron]

Hubert Chan wrote:

> That effectively kills all filenames that contain @,

> much worse than
> just a "metas" conflict IMHO.

I strongly agree:

- A restricted character in all names is far more
likely to impact users than a single restricted name. 


- Different "types" of directories, and extra rules
for dereferencing their contents, are extra concepts
for users to understand... this seems to run counter
to what I see as the overarching philosophy of
ReiserFS: unifying file system semantics.

I think that the meta directory needs to be thought of
not as a special directory, but as a normal directory
that has a name that is interpreted in a special way
by the system.

Markus Törnqvist wrote: 

> I'm not sure either what Hans Reiser meant by a
> macro, does that mean
> a settable variable? It's a decent compromise, I
> think. As someone
> else stated, let's just hope for an inoffensive
> default.

I agree.  This name will be used quite frequently in
the shell, and ReiserFS will be judged based on this
name (eg. if it is too long, if it is ugly, etc.). 
Case in point: Lisp, which is a phenomenal language
that people avoid because it has too many brackets. 
Same with Perl, that gets complaints because of its
heavy use of funny characters.  Aesthetics matter.

No one in this thread has commented on "+" as the
default meta directory name (one of the final
contenders in our previous thread on the subject). 
Again, the reasons:
- Short (one character)
- Makes sense in all languages (meaning "additional
information")
- Available on all int'l keyboards

Also, a question: are all meta files necessarily
pseudo files?  Should users be able to put regular
files in there to be interpreted as pseudo files? 
This will help to clarify some things for me.

Cheers,
N. Electron

P.S. I, too, want to reiterate that everyone has done
a great job on this file system and it is a remarkable
feat of design and computer engineering, and I'm very
thankful for your efforts.  I only offer my comments
because I care!


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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Christian Mayrhuber]

On Wednesday 31 March 2004 17:58, Narcoleptic Electron wrote:

> No one in this thread has commented on "+" as the
> default meta directory name (one of the final
> contenders in our previous thread on the subject).
> Again, the reasons:
> - Short (one character)
> - Makes sense in all languages (meaning "additional
> information")
I don't agree. It only makes sense if you know that you a
searching for additional information.
If a novice user encounters a directory called '+' for the first time, not 
knowing there is meta information available in reiser4, this will result in
a bug report, for sure.

If I had to choose between '+' and 'metas' I'd go with 'metas'.

-- 
lg, Chris

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Narcoleptic Electron]

Christian Mayrhuber wrote: 

> If a novice user encounters a directory called '+'
> for the first time, not 
> knowing there is meta information available in
> reiser4, this will result in
> a bug report, for sure.
>
> If I had to choose between '+' and 'metas' I'd go
> with 'metas'.

"Metas" is only meaningful in English.


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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hubert Chan]

>>>>> "Narcoleptic" == Narcoleptic Electron <narcoleptic_electron@yahoo.co.uk> writes:

[...]

Narcoleptic> "Metas" is only meaningful in English.

Well, "meta" (without the s) is a Greek prefix, so I assume it should
make some sense at least in Greek, and related languages.

Strictly speaking, though, the word "metas" doesn't even make sense in
English, unless you understand it as a shortening of metadata.

-- 
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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Christian Mayrhuber]

On Wednesday 31 March 2004 18:35, Narcoleptic Electron wrote:
> Christian Mayrhuber wrote:
> > If a novice user encounters a directory called '+'
> > for the first time, not
> > knowing there is meta information available in
> > reiser4, this will result in
> > a bug report, for sure.
> >
> > If I had to choose between '+' and 'metas' I'd go
> > with 'metas'.
>
> "Metas" is only meaningful in English.
>
>
> ______________________________________________________________________
> Post your free ad now! http://personals.yahoo.ca

No, according to babelfish

translation from

English: meta information 

to

Spanish: información del meta
French: l'information de méta
German: Metainformationen
Italian: le informazioni del meta
Portuguese: informação do meta

I've not tried how the plural translates...
I've not understood the chinese, korean and japanese icons. :-)
I don't know how bablefish handles words it doesn't know.

-- 
lg, Chris

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hubert Chan]

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

[...]

Elliott> Though you do have a point that the GUI tools filenames with
Elliott> '&' or '!'  becomes more common. '\' does have the advantage of
Elliott> simply needing to by typed twice (rather than one key followed
Elliott> by shift-number combo). Useful if you need to tell the tell the
Elliott> GUI what the file actually is.

Yes.  I think that \ is nice because you just have to type it twice in
the shell.  It is also a reserved character in DOS/Windows, so at least
Windows users won't be in the habit of naming their files with \.  (It's
also an uncommon character to begin with.)

One other problem, though, that I forgot to mention in my last post, is
that in the shell, or in a script, you would have to type it twice,
whereas in a GUI, you only have to type it once, which may lead to
confusion.

Overall, I in general don't like the idea of adding a new separator
character, but if we did, I think \ would be the way to go.

-- 
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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Narcoleptic Electron]

Christian Mayrhuber wrote: 

> On Wednesday 31 March 2004 18:35, Narcoleptic
> Electron wrote:
>
> > "Metas" is only meaningful in English.
>
> No, according to babelfish
> 
> translation from
> 
> English: meta information 
> 
> to
> 
> Spanish: información del meta
> French: l'information de méta
> German: Metainformationen
> Italian: le informazioni del meta
> Portuguese: informação do meta
> 
> I've not tried how the plural translates...
> I've not understood the chinese, korean and japanese
> icons. :-)

Yeah, I guess we can forget about those Chinese,
Korean and Japanese users.  [/sarcasm]

What I intended to say was: "Meta" is not meaningful
in all non-English languages.

While we're on the subject: it would not be necessary
to localize anything in the meta folder, as this is
for "system" use and essentially represents an API for
the parent object.  The meta folder itself, however,
occurs in user space.


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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Valdis.Kletnieks]

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

On Wed, 31 Mar 2004 11:43:35 +0300, mjt@nysv.org (Markus =?UNKNOWN?Q?T=F6rnqvist?=)  said:

> I'm not sure either what Hans Reiser meant by a macro, does that mean
> a settable variable? It's a decent compromise, I think. As someone
> else stated, let's just hope for an inoffensive default.

VMS has SYS$FOO variables all over the place, but they don't have the same
semantics as a Unix environment variables.  It's unclear what scope a settable
variable for this should have - systemwide, filesystem, process group, process,
thread, or file descriptor.  Equally good cases can be made for/against each of
them.


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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[The Amazing Dragon]

> From: Narcoleptic Electron <narcoleptic_electron@yahoo.co.uk>
> Hubert Chan wrote:
> > That effectively kills all filenames that contain @,
> 
> > much worse than
> > just a "metas" conflict IMHO.
> 
> I strongly agree:
> 
> - A restricted character in all names is far more
> likely to impact users than a single restricted name. 

This is why a couple candidates need to be brought up. Some seem good at
first glance, but are really bad choice after a bit of thought. So you're
right a badly chosen single character will be really bad. A good choice
needs to have minimal impact by being pretty much unused in filenames. A
corollary is that a badly chosen directory name will have a horrific
impact on users just as much as a badly chosen special character.

> I think that the meta directory needs to be thought of
> not as a special directory, but as a normal directory
> that has a name that is interpreted in a special way
> by the system.

In other words it is special, but it isn't special?

You can't have it both ways. "metas" is a perfectly valid filename on
all other filesystems. It is a valid word or partial word in several
languages, bad choice. Files/directories begining with . are at least
already handled specially by all tools. Names that are valid words are
precious, like gold you shouldn't steal them.

There is also the problem that things like Apache deliberately filter out
access to some files (like "..") because they're magic. By adding another
magic filename you've made those harder, at least begining it with . will
keep those tools' job easier (and you don't introduce a huge security
hole by adding a filesystem).

Also I feel it should be on the file itself. ie for the file /tmp/fooblah
you should be able to access the file's metadata by open()ing/using
readdir() on /tmp/fooblah/metas or (/tmp/fooblah/..metas or whatever).


> No one in this thread has commented on "+" as the
> default meta directory name (one of the final
> contenders in our previous thread on the subject). 
> Again, the reasons:
> - Short (one character)
> - Makes sense in all languages (meaning "additional
> information")
> - Available on all int'l keyboards

Bad choice. Note the "lost+found" directory found on *all* Unix
filesystems. If we need one more option | might be viable.

> Also, a question: are all meta files necessarily
> pseudo files?  Should users be able to put regular
> files in there to be interpreted as pseudo files? 
> This will help to clarify some things for me.

My impression is, that the metadata appears as normal files and is
accessible as normal files. Just gets interpreted in an interesting way.
I doubt metadata would have an owner or permissions separate from the
file/directory though. I imagine this is similar to Apple MacOS 10,
where all files have a mime-type that is accessible as
<filename>/mime-type.


-- 
(\___(\___(\______          --=> 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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Grant Miner]

> Also I feel it should be on the file itself. ie for the file /tmp/fooblah
> you should be able to access the file's metadata by open()ing/using
> readdir() on /tmp/fooblah/metas or (/tmp/fooblah/..metas or whatever).
> 
That's how it works now I believe.

> Bad choice. Note the "lost+found" directory found on *all* Unix
> filesystems. If we need one more option | might be viable.

Actually lost+found would not conflict if the directory were just + 
i.e. file/+/uid. Unless someone is proposing changing syntax so that 
accessing a file like foo@uid would get an attribute out of it (or 
foo+uid I suppose).  VMS does something similar, having a different 
syntax for each possible physical condition of a file (i.e., which 
device somethings on, which version, etc.)...a nightmare much worse than 
DOS with its drive letters.

The basic format for all VMS filenames is:
device:[directory.path]filename.extension;version

Example:
DISK$1:[JOE.PUBLIC_HTML]INDEX.HTML;1

There is no reason why all this information needs to be part of the syntax.

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Alexander G. M. Smith]

Elliott Mitchell wrote on Wed, 31 Mar 2004 21:46:14 -0800 (PST):
> Also I feel it should be on the file itself. ie for the file /tmp/fooblah
> you should be able to access the file's metadata by open()ing/using
> readdir() on /tmp/fooblah/metas or (/tmp/fooblah/..metas or whatever).

Sounds good to me.  I just hope that directory operations are
cheap in the file system.  The alternative of just adding a
..meta. prefix to all attribute names would cut out one level
of directories (less disk space usage, less lookup time to
resolve a path, and no worry about the weirdness of attributes
accidentally getting attached to the ..metas directory itself).

/tmp/fooblah/..metas/mime-type
/tmp/fooblah/..metas.mime-type

Hmmm.  Which is better?  The weirdness factor worries me
more than the performance reduction.

- Alex

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Narcoleptic Electron]

This discussion is spiralling out of control.  There
is far too much misunderstanding.  A discussion
summary is in order.

PROPOSALS:

1. Leave the "metas" directory as it is, for storing
the meta data hierarchy.

2. Rename "metas" to:
a) ..metas
b) @
c) +

3. Revise the architecture so that instead of putting
meta data into a directory, make it accessible via a
different path delimiter.  Proposals for a delimiter
include:
a) \
b) @
c) .

4. Return to the original approach of putting meta
data files into the parent directory, and prefixing
the name with:
a) ..metas.

PROBLEMS:

1. Name clashes with user files; "metas" does not have
meaning in all non-English languages; too long.

2. Name clashes with user files.
a) "..metas" does not have meaning in all non-English
languages; too long.
b) Conflict with an important mail application's
directory naming scheme.
c) No additional problems.

3. All file names containing the delimiter character
will cause problems; introduces a whole new [arguably
redundant] fundamental concept.  

4. A step backwards; dramatically increases chance of
name conflicts (since meta data is no longer in one
discrete location, but interspersed with user files).

If there are other approaches not addressed here, or
clarification required, please feel free to revise
this list.


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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Christian Iversen]

On Thursday 01 April 2004 18:31, Narcoleptic Electron wrote:
> If there are other approaches not addressed here, or
> clarification required, please feel free to revise
> this list.

I think someone suggested putting meta file information in /proc.

So. Is this a bad idea? I think not. 

In this scheme, /some/file would have /proc/metas/some/file/* as meta 
information. 

This reduces the risk of conflict to 0. 

One other idea I have, is "...". That way, 

dir/. is the directory itself
dir/.. is the parent
and
dir/... is the meta info.

Any comments?

-- 
Regards,
Christian Iversen

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Christian Mayrhuber]

On Thursday 01 April 2004 18:37, Christian Iversen wrote:
> On Thursday 01 April 2004 18:31, Narcoleptic Electron wrote:
> > If there are other approaches not addressed here, or
> > clarification required, please feel free to revise
> > this list.
>
> I think someone suggested putting meta file information in /proc.
>
> So. Is this a bad idea? I think not.
>
> In this scheme, /some/file would have /proc/metas/some/file/* as meta
> information.
Reiser4 would have to mimic the device structure in /proc.
If someone wants to access meta information he would have
to lookup the device of his filesystem.
What about nfs?
This is not compatible, nor comfortable.

>
> This reduces the risk of conflict to 0.
>
> One other idea I have, is "...". That way,
>
> dir/. is the directory itself
> dir/.. is the parent
> and
> dir/... is the meta info.
Really elegant!
Not perfect, tough - it is not descriptive, but "." and ".." are not
better in this regard, too.

I don't know any software using "..." files, so I'd say go for it, it's the
best suggestion so far, IMHO.

-- 
lg, Chris

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Tom Vier]

On Tue, Mar 30, 2004 at 09:50:23PM -0500, Hubert Chan wrote:
> That effectively kills all filenames that contain @, much worse than
> just a "metas" conflict IMHO.

the djbdns utils (eg, dnscache) use files starting with @ for cache files.

i would prefer ".meta" *without* the 's'! i would also like to suggest "..."
if it hasn't already been.

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0x15741ECE

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Tom Vier]

On Tue, Mar 30, 2004 at 09:04:08PM +0400, Nikita Danilov wrote:
> A character string that is used to identify a file. In the context of
> IEEE Std 1003.1-2001, a pathname consists of, at most, {PATH_MAX} bytes,
> including the terminating null byte. It has an optional beginning slash,

interesting. i thought posix, et al said PATH_MAX *not* including the nul
term. maybe i need to change all the str[PATH_MAX+1]; definitions i've made
in wipe.

google is my friend too, and i'll try to search the various 5000 *nix-like
standards. (heh, we need to standardize on one standard - i guess that's
what unix '98 was for.)

-- 
Tom Vier <tmv@comcast.net>
DSA Key ID 0x15741ECE

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Narcoleptic Electron]

I've attempted to incorporate all the new proposals. 
Please let me know if I've missed any.

Narcoleptic Electron wrote: 
> 
> PROPOSALS:
> 
> 1. Leave the "metas" directory as it is, for storing
> the meta data hierarchy.
> 
> 2. Rename "metas" to:
> a) ..metas
> b) @
> c) +

d) ..meta
e) ...

> 3. Revise the architecture so that instead of
> putting
> meta data into a directory, make it accessible via a
> different path delimiter.  Proposals for a delimiter
> include:
> a) \
> b) @
> c) .
> 
> 4. Return to the original approach of putting meta
> data files into the parent directory, and prefixing
> the name with:
> a) ..metas.

5. Create a "meta" directory in "/proc" whose contents
mirror the root file system, and contains all meta
data.
 
> PROBLEMS:
> 
> 1. Name clashes with user files; "metas" does not
> have
> meaning in all non-English languages; too long.
> 
> 2. Name clashes with user files.
> a) "..metas" does not have meaning in all
> non-English
> languages; too long.
> b) Conflict with an important mail application's
> directory naming scheme.

And the djbdns utils (eg, dnscache), whic use files
starting with @ for cache files.

> c) No additional problems.

d) More readable than "metas" in English, but suffers
the same problems.
e) This is reserved by Windows, making a Windows port
of ReiserFS impossible (I think this was the reason;
it was an objection raised by someone else during the
previous thread on this subject).  (The "..." approach
was my original suggestion on the original thread...)

> 3. All file names containing the delimiter character
> will cause problems; introduces a whole new
> [arguably
> redundant] fundamental concept.  
> 
> 4. A step backwards; dramatically increases chance
> of
> name conflicts (since meta data is no longer in one
> discrete location, but interspersed with user
> files).

5. We would need a way to differentiate regular
subdirectories in "/proc/meta/" with meta data
entries.
For example, consider "/proc/meta/foo/bar/baz": is
"baz" a metadata entry for "/foo/bar", or is "bar/baz"
metadata for "/foo"? 

N. Electron


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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hans Reiser]

Narcoleptic Electron wrote:

>This discussion is spiralling out of control.  There
>is far too much misunderstanding.  A discussion
>summary is in order.
>
>PROPOSALS:
>
>1. Leave the "metas" directory as it is, for storing
>the meta data hierarchy.
>  
>
We will do 1.

>2. Rename "metas" to:
>a) ..metas
>b) @
>c) +
>
>3. Revise the architecture so that instead of putting
>meta data into a directory, make it accessible via a
>different path delimiter.  Proposals for a delimiter
>include:
>a) \
>b) @
>c) .
>
>4. Return to the original approach of putting meta
>data files into the parent directory, and prefixing
>the name with:
>a) ..metas.
>
>PROBLEMS:
>
>1. Name clashes with user files; "metas" does not have
>meaning in all non-English languages; too long.
>
>2. Name clashes with user files.
>a) "..metas" does not have meaning in all non-English
>languages; too long.
>b) Conflict with an important mail application's
>directory naming scheme.
>c) No additional problems.
>
>3. All file names containing the delimiter character
>will cause problems; introduces a whole new [arguably
>redundant] fundamental concept.  
>
>4. A step backwards; dramatically increases chance of
>name conflicts (since meta data is no longer in one
>discrete location, but interspersed with user files).
>
>If there are other approaches not addressed here, or
>clarification required, please feel free to revise
>this list.
>
>
>______________________________________________________________________ 
>Post your free ad now! http://personals.yahoo.ca
>
>
>  
>


-- 
Hans

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Narcoleptic Electron]

Hans Reiser wrote: 

> Narcoleptic Electron wrote:
> 
> >1. Leave the "metas" directory as it is, for
> storing
> >the meta data hierarchy.
> >  
> >
> We will do 1.

What is the plan for addressing the name clash
problems that this causes?  (eg. I copy a directory,
that happens to contain a "metas" directory, to my
Reiser4 partition)


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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[The Amazing Dragon]

> From: Narcoleptic Electron <narcoleptic_electron@yahoo.co.uk>
> 
> I've attempted to incorporate all the new proposals. 
> Please let me know if I've missed any.
> 
> Narcoleptic Electron wrote: 
>  
> > PROBLEMS:
> > 
> > 1. Name clashes with user files; "metas" does not
> > have
> > meaning in all non-English languages; too long.

The latter two are pretty trivial, how meaningful is "lost+found" in
other languages, five characters is that long?

I feel the first item on that list is fatal though. I be *very* worried
about the ReiserFS v4 patch being rejected from the kernel due to this.
Real filenames in any language should be considered precious, and not
stolen without a *very* good reason. This is a decent reason, but utterly
short of being good enough.

> > b) Conflict with an important mail application's
> > directory naming scheme.
> 
> And the djbdns utils (eg, dnscache), whic use files
> starting with @ for cache files.

In other words, problems with multiple applications; fatal flaw. Though
not a common one, short and therefore precious.

> > c) No additional problems.

Still short and therefore precious. There could be multiple unknown
applications that use it. Already commonly used in filenames (though not
by itself).

> e) This is reserved by Windows, making a Windows port
> of ReiserFS impossible (I think this was the reason;
> it was an objection raised by someone else during the
> previous thread on this subject).  (The "..." approach
> was my original suggestion on the original thread...)

On which systems you could use / as the metadata separator.

> > 3. All file names containing the delimiter character
> > will cause problems; introduces a whole new
> > [arguably
> > redundant] fundamental concept.  

Not without president though, notably MacOS 10 metadata appears when
accessing a file as a directory. Only MacOS 10 doesn't include a new
separator.

> 5. We would need a way to differentiate regular
> subdirectories in "/proc/meta/" with meta data
> entries.
> For example, consider "/proc/meta/foo/bar/baz": is
> "baz" a metadata entry for "/foo/bar", or is "bar/baz"
> metadata for "/foo"? 

The problems are *much* bigger than this. For one thing, there is the
already mentioned problem, this completely breaks across network
filesystems. The *very* much larger problem is the overhead. If I want
to access the metadata for an arbitrary file you have to use getwd()
which may in turn stat() every file in several directories. If you're
interacting with a user, the overhead isn't bad, but if you're doing a
couple hundred of these overhead is a severe problem.


-- 
(\___(\___(\______          --=> 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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hans Reiser]

Narcoleptic Electron wrote:

>Hans Reiser wrote: 
>
>  
>
>>Narcoleptic Electron wrote:
>>
>>    
>>
>>>1. Leave the "metas" directory as it is, for
>>>      
>>>
>>storing
>>    
>>
>>>the meta data hierarchy.
>>> 
>>>
>>>      
>>>
>>We will do 1.
>>    
>>
>
>What is the plan for addressing the name clash
>problems that this causes?  (eg. I copy a directory,
>that happens to contain a "metas" directory, to my
>Reiser4 partition)
>  
>
these problems will not exist significantly in reality.  Look at netapps 
and snapshots and clearcase and other filesystems, I remember wondering 
if .snapshot could be a problem when netapps were new and it was never a 
problem.

People who find it is a problem can #define it to something else.  If 5 
people bother to do so, I will be surprised.

Many languages have reserved keywords.....


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


-- 
Hans

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[cami]

>>>> 1. Leave the "metas" directory as it is, for storing
>>>> the meta data hierarchy.
>>>
>>> We will do 1.
>>
>> What is the plan for addressing the name clash
>> problems that this causes?  (eg. I copy a directory,
>> that happens to contain a "metas" directory, to my
>> Reiser4 partition)
>>
> these problems will not exist significantly in reality.  Look at netapps 
> and snapshots and clearcase and other filesystems, I remember wondering 
> if .snapshot could be a problem when netapps were new and it was never a 
> problem.
> 
> People who find it is a problem can #define it to something else.  If 5 
> people bother to do so, I will be surprised.
> 
> Many languages have reserved keywords.....

Not sure if anyone  has bothered to check if this would
impose the  limitation  that  people are worried about.

 From a  quick glance,  none  of  the linux distro's have
ever  had  a  file / directory  called  "metas"  before.
`metas`  isn't even a real a word anyway  (at  least not
an english word) so the chances of  it being a big issue
are very very  small..  freshmeat.net's search shows not
even one hit  for  the word  metas and  that pretty much
the majority of linux/coding related projects..

Regards,
Cami

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Narcoleptic Electron]

Hans Reiser wrote: 

> Narcoleptic Electron wrote:
> 
> >What is the plan for addressing the name clash
> >problems that this causes?  (eg. I copy a 
> >directory,
> >that happens to contain a "metas" directory, to my
> >Reiser4 partition)
>  
> these problems will not exist significantly in
> reality.  Look at netapps 
> and snapshots and clearcase and other filesystems, I
> remember wondering 
> if .snapshot could be a problem when netapps were
> new and it was never a 
> problem.

I do not disagree that it is unlikely.  However, it is
still possible, so my question remains: what happens
in the scenario I describe?

> People who find it is a problem can #define it to
> something else.  If 5 
> people bother to do so, I will be surprised.

True; as long as everyone refers to the "metas"
directory properly (using an environment variable, for
example, as opposed to hard-coding the string "metas"
anywhere), it will be fine.

> Many languages have reserved keywords.....

We're not talking about a language here, though...
we're talking about a namespace.  To me, the measure
of usefulness of a namespace is the ability to provide
names... reserved words hamper that ability.  The
perfect namespace has no reserved words; at worst,
only  reserved characters, with escape sequences
provided for each so that any name is still possible.


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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hubert Chan]

>>>>> "Narcoleptic" == Narcoleptic Electron <narcoleptic_electron@yahoo.co.uk> writes:

[...]

Narcoleptic> True; as long as everyone refers to the "metas" directory
Narcoleptic> properly (using an environment variable, for example, as
Narcoleptic> opposed to hard-coding the string "metas" anywhere), it
Narcoleptic> will be fine.

Hmm.  Maybe have a /proc/fs/reiser4/metas file to query it?
(Environment variable seems fragile.)

-- 
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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Christian Iversen]

On Sunday 04 April 2004 06:28, Hubert Chan wrote:
> >>>>> "Narcoleptic" == Narcoleptic Electron
> >>>>> <narcoleptic_electron@yahoo.co.uk> writes:
>
> [...]
>
> Narcoleptic> True; as long as everyone refers to the "metas" directory
> Narcoleptic> properly (using an environment variable, for example, as
> Narcoleptic> opposed to hard-coding the string "metas" anywhere), it
> Narcoleptic> will be fine.
>
> Hmm.  Maybe have a /proc/fs/reiser4/metas file to query it?
> (Environment variable seems fragile.)

Good idea. Of course, I will be the first one to set it to "..." ;-)

-- 
Regards,
Christian Iversen

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Grant Miner]

>I do not disagree that it is unlikely.  However, it is
>still possible, so my question remains: what happens
>in the scenario I describe?
>
>  
>
Hi
What happens now is open() returns EEXIST (file exists) error; reiser4 
can't make the file.  Is this what you mean?

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Grant Miner]

Hubert Chan wrote:

>>>>>>"Narcoleptic" == Narcoleptic Electron <narcoleptic_electron@yahoo.co.uk> writes:
>>>>>>            
>>>>>>
>
>[...]
>
>Narcoleptic> True; as long as everyone refers to the "metas" directory
>Narcoleptic> properly (using an environment variable, for example, as
>Narcoleptic> opposed to hard-coding the string "metas" anywhere), it
>Narcoleptic> will be fine.
>
>Hmm.  Maybe have a /proc/fs/reiser4/metas file to query it?
>(Environment variable seems fragile.)
>
>  
>
You mean /sys/fs/reiser4/metas?  :P

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Narcoleptic Electron]

Christian Iversen wrote: 

> On Sunday 04 April 2004 06:28, Hubert Chan wrote:
>
> > >>>>> "Narcoleptic" == Narcoleptic Electron
> > >>>>> writes:
> >
> > Narcoleptic> True; as long as everyone refers to
> the "metas" directory
> > Narcoleptic> properly (using an environment
> variable, for example, as
> > Narcoleptic> opposed to hard-coding the string
> "metas" anywhere), it
> > Narcoleptic> will be fine.
> >
> > Hmm.  Maybe have a /proc/fs/reiser4/metas file to
> query it?
> > (Environment variable seems fragile.)
> 
> Good idea. Of course, I will be the first one to set
> it to "..." ;-)

Yes, a "/proc/fs/reiser4/metas" file containing the
meta directory name is a far better approach than
putting it in an environment variable (that was just
the first thing that came to my mind to demonstrate
the point).


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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hubert Chan]

>>>>> "Grant" == Grant Miner <mine0057@mrs.umn.edu> writes:

Grant> You mean /sys/fs/reiser4/metas?  :P

My /sys doesn't even have a fs subdirectory.  So I'm pretty sure I mean
/proc (unless you can tell me why it should be in /sys.  But AFAICT /sys
deals more with accessing hardware properties.).

-- 
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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[The Amazing Dragon]

> From: Hans Reiser <reiser@namesys.com>
> these problems will not exist significantly in reality.  Look at netapps 
> and snapshots and clearcase and other filesystems, I remember wondering 
> if .snapshot could be a problem when netapps were new and it was never a 
> problem.

Notice though that that filename begins with ".", not a letter. This
causes all programs to treat it specially. Also note that that filename
is nine characters long, and therefore making a purely random collision
less likely by more than four orders of magnitude.

> People who find it is a problem can #define it to something else.  If 5 
> people bother to do so, I will be surprised.
> 
> Many languages have reserved keywords.....

I REJECT THIS!

I believe Ada is almost the only programming language without reserved
words. The thing is a filesystem is NOT a programming language! It is
designed to handle files with arbitrary names, no matter how odd. Only
programmers deal with C, end users must deal with filesystem limitations.

> From: cami <camis@mweb.co.za>
> Not sure if anyone  has bothered to check if this would
> impose the  limitation  that  people are worried about.
> 
>  From a  quick glance,  none  of  the linux distro's have
> ever  had  a  file / directory  called  "metas"  before.
> `metas`  isn't even a real a word anyway  (at  least not
> an english word) so the chances of  it being a big issue
> are very very  small..  freshmeat.net's search shows not
> even one hit  for  the word  metas and  that pretty much
> the majority of linux/coding related projects..

Good point, search engines as evidence. The problem is you're only
looking at distributions, which are going to be highly similar and you're
completely missing end users. So let us take this to a full search engine
and see what turns up...  Hmm, roughly a million hits, let us look at a
few samples:

http://www.metas.ch/
http://vancouver-webpages.com/META/mk-metas.html
http://www.metas.com.br/
http://metas.enfermeria21.com/
http://www.metas.com.mx/

Okay, out of one million hits, we randomly look at ten, and half feature
"metas" in the URL somewhere. Going the other direction, Google indexes
roughly 4 billion pages. If we guess the above search was representative,
roughly 500,000 pages will include "metas" somewhere in the URL, possibly
only as a hostname, but somewhere. So we've managed to collect 1 out of
every 10,000 pages that Google indexes. Though we don't have a direct
proof, I hope I've come close enough to scare you.

Hans, what will it take for you to change your mind?


-- 
(\___(\___(\______          --=> 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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hubert Chan]

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

[...]

The> Good point, search engines as evidence. The problem is you're only
The> looking at distributions, which are going to be highly similar and
The> you're completely missing end users. So let us take this to a full
The> search engine and see what turns up...  Hmm, roughly a million
The> hits, let us look at a few samples:

I'm only getting a bit less than 600,000.  Maybe we caught Google in the
middle of some reindexing.  But anyways...

Most of the pages seem to be Spanish and Portuguese.  Google translation
translates "metas" as "goals".  Are there any Spanish or Portuguese
speakers on this list to confirm that?

Since "goals" is a fairly common word, it probably is a bad idea to use
"metas" without at least some sort of prefix.

-- 
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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Cami]

> Good point, search engines as evidence. The problem is you're only
> looking at distributions, which are going to be highly similar and you're
> completely missing end users. So let us take this to a full search engine
> and see what turns up...  Hmm, roughly a million hits, let us look at a
> few samples:
> 
> http://www.metas.ch/
> http://vancouver-webpages.com/META/mk-metas.html
> http://www.metas.com.br/
> http://metas.enfermeria21.com/
> http://www.metas.com.mx/
> 
> Okay, out of one million hits, we randomly look at ten, and half feature
> "metas" in the URL somewhere. Going the other direction, Google indexes
> roughly 4 billion pages. If we guess the above search was representative,
> roughly 500,000 pages will include "metas" somewhere in the URL, possibly
> only as a hostname, but somewhere. So we've managed to collect 1 out of
> every 10,000 pages that Google indexes. Though we don't have a direct
> proof, I hope I've come close enough to scare you.

Quite true.. "..metas" or ".metas" would be the better choice..

Regards,
Cami

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Marcelo Pacheco]

Exactly. Metas is goals/objectives in portuguese. Although it's extremelly 
uncommon to have files without extensions, I would still much rather prefer 
having .metas instead of metas.

Marcelo Pacheco

On Monday 05 April 2004 02:01, Hubert Chan wrote:
> >>>>> "The" == The Amazing Dragon (Elliott Mitchell) <ehem@cs.pdx.edu>
> >>>>> writes:
>
> [...]
>
> The> Good point, search engines as evidence. The problem is you're only
> The> looking at distributions, which are going to be highly similar and
> The> you're completely missing end users. So let us take this to a full
> The> search engine and see what turns up...  Hmm, roughly a million
> The> hits, let us look at a few samples:
>
> I'm only getting a bit less than 600,000.  Maybe we caught Google in the
> middle of some reindexing.  But anyways...
>
> Most of the pages seem to be Spanish and Portuguese.  Google translation
> translates "metas" as "goals".  Are there any Spanish or Portuguese
> speakers on this list to confirm that?
>
> Since "goals" is a fairly common word, it probably is a bad idea to use
> "metas" without at least some sort of prefix.

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Miguel]

On Mon, 05 Apr 2004 01:01:39 -0400
Hubert Chan <hubert@uhoreg.ca> wrote:

> >>>>> "The" == The Amazing Dragon (Elliott Mitchell) <ehem@cs.pdx.edu>
> >writes:
> 
> [...]
> 
> The> Good point, search engines as evidence. The problem is you're
> only The> looking at distributions, which are going to be highly
> similar and The> you're completely missing end users. So let us take
> this to a full The> search engine and see what turns up...  Hmm,
> roughly a million The> hits, let us look at a few samples:
> 
> I'm only getting a bit less than 600,000.  Maybe we caught Google in
> the middle of some reindexing.  But anyways...
> 
> Most of the pages seem to be Spanish and Portuguese.  Google
> translation translates "metas" as "goals".  Are there any Spanish or
> Portuguese speakers on this list to confirm that?

Yes, This is correct and one time I see a project that used a file
called metas in similar mean of the TODO file to state its goals,  but
nothing to care about IMHO.

ermmmm a dot doens't hurt... 


> 
> Since "goals" is a fairly common word, it probably is a bad idea to
> use"metas" without at least some sort of prefix.


-- 
La resistencia es fútil todos seréis asimilados

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hans Reiser]

Marcelo Pacheco wrote:

>Exactly. Metas is goals/objectives in portuguese. 
>
>  
>
New users hate languages with lots of punctuation in the keywords.  Mr. 
Demidov correctly reminded me of this, and of the history of users 
hating such languages, and this caused me to abandon ..metas for metas.  
Mr Demidov, can you say more about this history?

What about "meths" (short for methods)?  Is that a word in any language?

-- 
Hans

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Nikita Danilov]

Hans Reiser writes:
 > Marcelo Pacheco wrote:
 > 
 > >Exactly. Metas is goals/objectives in portuguese. 
 > >
 > >  
 > >
 > New users hate languages with lots of punctuation in the keywords.  Mr. 
 > Demidov correctly reminded me of this, and of the history of users 
 > hating such languages, and this caused me to abandon ..metas for metas.  

Hmm... last time you claimed that is were users on reiserfs-list who won
an argument with you about naming. Now it turns that nobody except you
is in favor of this name.

 > Mr Demidov, can you say more about this history?
 > 
 > What about "meths" (short for methods)?  Is that a word in any language?

It means "methylated spirits" in... English. Probably refers to the
state of mind it takes to deal with "unified namespace".

 > 
 > -- 
 > Hans
 > 

Nikita.

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Valdis.Kletnieks]

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

On Tue, 06 Apr 2004 07:30:07 PDT, Hans Reiser said:

> What about "meths" (short for methods)?  Is that a word in any language?

Well, there's crystal meth, but I'd consider it highly unlikely that anybody
using that stuff can get their act together enough to care about metadata. :)


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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[camis]

>What about "meths" (short for methods)?  Is that a word in any language?

Meths is word already in english..

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Nikita Danilov]

camis writes:
 > >What about "meths" (short for methods)?  Is that a word in any language?
 > 
 > Meths is word already in english..

Indeed, meths is plural of meth which is (rare) synonym for "a meath",
"a mead", Russian "m'od":

From Webster's Revised Unabridged Dictionary (1913) [web1913]:

  Meath \Meath\, Meathe \Meathe\, n. [See {Mead}.]
     A sweet liquor; mead. [Obs.] --Chaucer. Milton.

Nikita.

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Valdis.Kletnieks]

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

On Tue, 06 Apr 2004 23:05:45 +0400, Nikita Danilov said:
>   Meath \Meath\, Meathe \Meathe\, n. [See {Mead}.]
>      A sweet liquor; mead. [Obs.] --Chaucer. Milton.

On the other hand, both those Chaucer and Milton blokes have
been dust for quite some time, and the language has moved on.

Does anybody outside the Renaissance Fair circuit still even drink mead? ;)


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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Richard Heycock]

On Wed, 2004-04-07 at 05:14, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 06 Apr 2004 23:05:45 +0400, Nikita Danilov said:
> >   Meath \Meath\, Meathe \Meathe\, n. [See {Mead}.]
> >      A sweet liquor; mead. [Obs.] --Chaucer. Milton.
> 
> On the other hand, both those Chaucer and Milton blokes have
> been dust for quite some time, and the language has moved on.
> 
> Does anybody outside the Renaissance Fair circuit still even drink mead? ;)

I'm rather partial to a drop of mead if I can get my hands on it? Though
metadata is not something I think about if I do drink it!

rgh

-- 
"It is possible to make things of great complexity out of things
 that are very simple. There is no conservation of simplicity"
 -- Stephen Wolfram

Richard Heycock <rgh@roughage.com.au>
tel : 0410 646 369
key fingerprint : 909D CBFA C669 AC2F A937 AFA4 661B 9D21 EAAB 4291

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[mjt]

Valdis Kletnieks wrote:

>Does anybody outside the Renaissance Fair circuit still even drink mead? ;)

Yes, as a matter of fact they do ;)

I don't know how typical it is even for a Finn, but I prefer mead over
most other beverages, and even have some recipes for it.

But to get back to the point. "meths" is NOT a good word, like crystal
meth or whatever, it's almost more a word than "metas" (maybe most people
would just use "meta" as a directory name)

I mean, most of this discussion has been, pardon my French, bullshit.
..metas/ is still a good solution, it's prefixed in a manner that most
stuff is not, the prefix makes sense as being "really hidden" and metas
is not as probable a word as meta and it's still easily accessible.
Hell, it used to be prefixed like that before it was a unified
directory.

Whatever. I'm tired. I'm sure everyone has their opinion on this matter
and I'm also sure the guys at Namesys are farting blood because of
this discussion. Whatever people want as their meta directory name they
will patch or macro or edit in. If there's enough dispersion it will
be shown in /proc/ or /sys/ or wherever, even if not an environmental
variable.

Let's be reasonable and concentrate on something more important, like
brewing good mead or how to protect the metadata integrity or
something.

I, for one, will not participate in this thread again.

-- 
mjt

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hubert Chan]

>>>>> "Hans" == Hans Reiser <reiser@namesys.com> writes:

Hans> New users hate languages with lots of punctuation in the keywords.
Hans> Mr. Demidov correctly reminded me of this, and of the history of
Hans> users hating such languages, and this caused me to abandon ..metas
Hans> for metas.  Mr Demidov, can you say more about this history?

Well, I don't know exactly what Mr. Demidov was thinking, but I know
that one common complaint about Perl is the punctuation in front of
variable names.  However, for UNIX filesystems, there's a lot of
precedent for at least a single leading dot in filenames, so I don't
think it should be a problem to call it ".metas".  It is also not
something that would be extremely common, so it wouldn't be like having
a Perl program pocked with punctuation.  (Alliteration unintentional.)

The leading dot also flags the file as being somewhat "special" -- two
leading dots would flag it as being more so.  Although my own personal
sense of aesthetics is biased against two dots, using two dots would be
well justified, and I personally wouldn't consider it a critical issue.

-- 
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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Dave Poirier]

----- Original Message -----
From: Hubert Chan <hubert@uhoreg.ca>
Date: Wednesday, April 7, 2004 1:07 pm
Subject: Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

(snip!)
> Well, I don't know exactly what Mr. Demidov was thinking, but I know
> that one common complaint about Perl is the punctuation in front of
> variable names.  However, for UNIX filesystems, there's a lot of
> precedent for at least a single leading dot in filenames, so I don't
> think it should be a problem to call it ".metas".  It is also not
> something that would be extremely common, so it wouldn't be like
> havinga Perl program pocked with punctuation.  (Alliteration
> unintentional.)
> The leading dot also flags the file as being somewhat "special" -- two
> leading dots would flag it as being more so.  Although my own personal
> sense of aesthetics is biased against two dots, using two dots
> would be
> well justified, and I personally wouldn't consider it a critical
> issue.
(snip!)

I was thinking from a user point of view when browsing a directory structure or even simply listing files, normally files/directories starting with a single dot are hidden (by default), and in graphical modes their icons are shaded to signify they are special files/directories.

I believe it would make sense to have the "metas" folder hidden or shaded rather than always displayed, it would be less intrusive for users not requiring access to those files.

Sorry for the intrusion, I'm kindof new to this list, looking forward to collaborate with you all,

Dave Poirier
Unununium Operating System
http://unununium.org/

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hubert Chan]

>>>>> "Dave" == Dave Poirier <dpoirier@dsfm.mb.ca> writes:

[...]

Dave> I was thinking from a user point of view when browsing a directory
Dave> structure or even simply listing files, normally files/directories
Dave> starting with a single dot are hidden (by default), and in
Dave> graphical modes their icons are shaded to signify they are special
Dave> files/directories.

Dave> I believe it would make sense to have the "metas" folder hidden or
Dave> shaded rather than always displayed, it would be less intrusive
Dave> for users not requiring access to those files.

The metas directory is "hidden" anyways, because it is not returned by
readdir(3).

-- 
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: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Stewart Smith]

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

On Tue, 2004-03-30 at 14:22, Scott Young wrote:
> by putting a / at the end of their name.  Folders are more complicated,
> but I think it should be done by just adding a slash after the full
> directory name (full as in including a trailing slash, so therefore
> there would be two slashes at the end to access an attribute). 
> /home//attribute would be the an attribute on the home directory. 

This behaviour would be broken, as you can have many slashes together
and they just get collapsed as one. This has been so on unixes for a
very long time (try 'ls ////////////////////////////////' on your system
:)

A lot of things would break if // suddenly meant something different. 

-- 
Stewart Smith (stewart@flamingspork.com)
http://www.flamingspork.com/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Beni Cherniavsky]

Christian Iversen wrote:
> On Sunday 04 April 2004 06:28, Hubert Chan wrote:
> 
>>>>>>>"Narcoleptic" == Narcoleptic Electron
>>>>>>><narcoleptic_electron@yahoo.co.uk> writes:
>>
>>[...]
>>
>>Narcoleptic> True; as long as everyone refers to the "metas" directory
>>Narcoleptic> properly (using an environment variable, for example, as
>>Narcoleptic> opposed to hard-coding the string "metas" anywhere), it
>>Narcoleptic> will be fine.
>>
>>Hmm.  Maybe have a /proc/fs/reiser4/metas file to query it?
>>(Environment variable seems fragile.)
> 
That's the only right (and feasible) way to export it from the kernel.
However it's purpose is to allow writing scripts that are portable 
accross different definitions and this is much easier with an 
environment variable (cat foo/$REISER4FS_METAS/rwx) than with a file
(cat foo/`cat /proc/fs/reiser4/metas`/rwx).  So people will surely
set an environment variable from the /proc file in some shell init file.
Not that standardazing the name of the environment variable should 
bother us now.

> 
> Good idea. Of course, I will be the first one to set it to "..." ;-)
> 
Note that changing the magic name (dynamically or even by recompiling) 
can create a confilict with an *exisiting* file on a reiserfs4 partition 
(the file could have been created when another name was magic).  The FS 
code should be ready to handle it, preferably giving some escape route 
way to access the colliding file (e.g. ``foo/my_metas/escape`` could 
give access to the file known as ``foo/my_metas`` before you changed the 
magic name to ``my_metas``).

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Narcoleptic Electron]

Beni Cherniavsky wrote: 

> Note that changing the magic name (dynamically or
> even by recompiling) 
> can create a confilict with an *exisiting* file on a
> reiserfs4 partition 
> (the file could have been created when another name
> was magic).  The FS 
> code should be ready to handle it, preferably giving
> some escape route 
> way to access the colliding file (e.g.
> ``foo/my_metas/escape`` could 
> give access to the file known as ``foo/my_metas``
> before you changed the 
> magic name to ``my_metas``).

That is a very good point, and I think your solution
is the right way to get around it.


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

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hans Reiser]

Narcoleptic Electron wrote:

>Beni Cherniavsky wrote: 
>
>  
>
>>Note that changing the magic name (dynamically or
>>even by recompiling) 
>>can create a confilict with an *exisiting* file on a
>>reiserfs4 partition 
>>(the file could have been created when another name
>>was magic).  The FS 
>>code should be ready to handle it, preferably giving
>>some escape route 
>>way to access the colliding file (e.g.
>>``foo/my_metas/escape`` could 
>>give access to the file known as ``foo/my_metas``
>>before you changed the 
>>magic name to ``my_metas``).
>>    
>>
>
>That is a very good point, and I think your solution
>is the right way to get around it.
>
>
>______________________________________________________________________ 
>Post your free ad now! http://personals.yahoo.ca
>
>
>  
>
I think we should have a /metasoff hidden directory that presents the 
filesystem tree but without the metas.

Of course, now that we have funding for views, when that is completed 
you will be able to specify a view that cannot access metas.

-- 
Hans

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[John D. Heintz]

Hans Reiser wrote:

>
> Of course, now that we have funding for views, when that is completed 
> you will be able to specify a view that cannot access metas.
>
First, congratulations on getting the funding!

Second, I'm curious! Would views enable disambiguating conflicted names 
from plugins?

Thanks,
John Heintz

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Clifford Beshers]

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

Hans Reiser wrote:

> Grant Miner wrote:
>
>> Someone mentioned earlier, and I like just the at sign: @ Think of it 
>> short for "attributes".
>>
>> file/@/uid
>>
>> The nice thing about @ is it shows up early lexicographically, it's 
>> short and unlikely to be used.  This name is important to pick well 
>> because it will likely set a long precedent.
>>
> It would be a problem for utilities like scp....
>
Hans, are you sure?  I tried some examples and had no troubles.  From my 
history:

      588  cd ~/tmp
      589  mkdir -p foo/@
      590  touch foo/@/uid
      591  scp -rp foo/@/uid stan:/tmp
      592  ssh stan 'mkdir -p /tmp/foo/@ ; touch /tmp/foo/@/uid'
      593  scp -rp stan:/tmp/foo/@ .

I'm not sure if @ is a good choice or not, but I don't think it would 
actually cause trouble syntactically, because everything expecting 
hostnames looks for a colon.

--

This message contains information which may be confidential and privileged. Unless you are the 
addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone 
the message or any information contained in the message. If you have received the message in error, 
please advise the sender and delete the message.  Thank you.

[-- Attachment #2: Type: text/html, Size: 1769 bytes --]

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hans Reiser]

Grant Miner wrote:

> Someone mentioned earlier, and I like just the at sign: @ Think of it 
> short for "attributes".
>
> file/@/uid
>
> The nice thing about @ is it shows up early lexicographically, it's 
> short and unlikely to be used.  This name is important to pick well 
> because it will likely set a long precedent.
>
>
It would be a problem for utilities like scp....

-- 
Hans

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[mjt]

On Fri, May 14, 2004 at 12:41:15PM -0700, Clifford Beshers wrote:
>I'm not sure if @ is a good choice or not, but I don't think it would 
>actually cause trouble syntactically, because everything expecting 
>hostnames looks for a colon.

This has been discussed. There is the mailer that uses an @-named
symlink to the current message. Can't remember which one.

-- 
mjt

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Hans Reiser]

You are probably right about scp specifically, but in general @ is used by 
some things that expect it to mean user@host.  @ could be used, I think 
clearcase used it, I just don't see it as better than "metas".

Hans

On Friday 14 May 2004 12:41, Clifford Beshers wrote:
> Hans Reiser wrote:
> > Grant Miner wrote:
> >> Someone mentioned earlier, and I like just the at sign: @ Think of it
> >> short for "attributes".
> >>
> >> file/@/uid
> >>
> >> The nice thing about @ is it shows up early lexicographically, it's
> >> short and unlikely to be used.  This name is important to pick well
> >> because it will likely set a long precedent.
> >
> > It would be a problem for utilities like scp....
>
> Hans, are you sure?  I tried some examples and had no troubles.  From my
> history:
>
>       588  cd ~/tmp
>       589  mkdir -p foo/@
>       590  touch foo/@/uid
>       591  scp -rp foo/@/uid stan:/tmp
>       592  ssh stan 'mkdir -p /tmp/foo/@ ; touch /tmp/foo/@/uid'
>       593  scp -rp stan:/tmp/foo/@ .
>
> I'm not sure if @ is a good choice or not, but I don't think it would
> actually cause trouble syntactically, because everything expecting
> hostnames looks for a colon.
>
> --
>
> This message contains information which may be confidential and privileged.
> Unless you are the addressee (or authorized to receive for the addressee),
> you may not use, copy or disclose to anyone the message or any information
> contained in the message. If you have received the message in error, please
> advise the sender and delete the message.  Thank you.

Re: [PATCH] "metas" in reiserfs v4 snapshot 2004.03.26

[Valdis.Kletnieks]

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

On Sat, 15 May 2004 14:10:10 +0300, Markus =?UNKNOWN?Q?T=F6rnqvist?= said:

> This has been discussed. There is the mailer that uses an @-named
> symlink to the current message. Can't remember which one.

That would be MH, nhm, and exmh...

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