"metas" in reiserfs v4 snapshot 2004.03.26

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
},

diff -ruN /home/peter/linux/fs/reiser4/plugin/pseudo/pseudo.c linux/fs/reiser4/plugin/pseudo/pseudo.c
@@ -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
 		},

The name clashing is less important than the greater user friendliness. Users on the mailing list convinced me of this.

Hans

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

[...]

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 <[email protected]> - 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.

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...).

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

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

Hans

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

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.

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.

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

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?

...

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

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.

"/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.

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.

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

This is per se not a bad idea, imo.

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.

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

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 <[email protected]> - 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.

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 <=--          ______/)___/)___/)
 \   (    |         [email protected]      PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/

[...]

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 <[email protected]> - 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.

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 <=--          ______/)___/)___/)
 \   (    |         [email protected]      PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/

On Tue, 2004-03-30 at 23:20, The Amazing Dragon wrote:
[snip]

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 <[email protected]>
eSoft, Inc.

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

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

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.

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

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

"Metas" is only meaningful in English.

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

[...]

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 <[email protected]> - 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.

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

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

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.

[...]

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 <[email protected]> - 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.

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

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

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 <[email protected]>
DSA Key ID 0x15741ECE

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

----------------------------------------------------------------------
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.

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 <[email protected]>
DSA Key ID 0x15741ECE

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

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 <[email protected]> - 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.

[...]

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 <[email protected]> - 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.

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 ([email protected])
http://www.flamingspork.com/

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

It would be a problem for utilities like scp....

Hans

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.

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

mjt

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

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

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

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

As an avid fan and supporter, active member on the IRC channel, I must disagree.

There have been good points here on the list, about tar balls which may contain a metas/ directory and that less special directories are MORE user-friendlyness.

It may superficially seem equal, if there's a directory that's invisible, but still exists. I mean, the name of the directory may seem unimportant.

It is not. Anyone who wants to use the metas will know how to do it, no matter what the name. I think Piotr Neuman's patch is a prerequisite for getting this baby into the mainline kernel.

..pseudo/ was a good solution, ..metas/ is more descriptive and just as inoffensive.

I ask you to reconsider your take on this and I for one will continue to use ..metas/ just because I want to be able to trust my computer. It is my tool to do my bidding, not to think for me or make assumptions, like "Gee, that mjt fool will never want a directory named metas/"

Thank you!

mjt

As a complete reiserfs outsider, who is just interested in using a good filesystem, I agree :)

If I had anything to say, I would go for ".meta".

Using a name like "metas" WILL introduce breakage in many cases. As previously
mentioned: tar-balls, user scripts and other cases.

But who am I to tell you that?... I'm not a reiserfs developer ;)

Regards,
Christian Iversen

(BTW, Why can't I fake the In-Reply-To header properly, not being a subscriber but not wanting to break threads either?

It makes sense, it's hidden except for ls -a, but being a special case it's still invisible to readdir.

My personal take on this still is that ..metas/ makes more sense, like the extra dot signifying "I am really hidden" ;)

mjt

I also suggest "..meta" as best choice. This way one can avoid the (remote
but possible) case of having an application who wants to create a ".meta" configuration file/directory in your $HOME.

Claudio