Pavel Machek wrote:
>Hi!
>
>
>
>>Answer: choose obscure names
>>
>>Problem (all credit to Mr. Demidov for identifying this problem, I
>>argued the other viewpoint, and I can only claim the wisdom to know
>>that I lost the argument): names like "..metas" are ugly to new users,
>>who don't really care for languages that use punctuation in their
>>keywords.
>>
>>Answer
>>
>>don't make them too obscure, experienced namespace developers know
>>that the problem of polluting the namespace is not really as big a
>>deal as beginners think it is, and Clearcase and the WAFL filesystem
>>manage to get by just fine, whereas the problem of putting punctuation
>>marks into names and syntax is a big deal for newbies to the system.
>>Name it "metas" not "..metas", and users will never experience it as a
>>real problem, and newbies will never be annoyed by a-rhythmic
>>punctuation. Note: if Linus disagrees, it is not the most important
>>thing in this design, "..metas" isn't the end of the world.
>>
>>
>
>What about choosing just "..." instead of "metas"? "metas" is string
>that needs translation etc, while "..." is nicely neutral.
>
>cat /sound_of_silence.mp3/.../author
>
>does not look bad, either...
> Pavel
>
>
"..." is pretty good, but I think it has been used by others, but I
really forget who. I could live with "...", but I think "metas" and
"..metas" will collide less often. Apparently Meta is a finnish name or
something, so Linus does not like it. The exact string is really not
very important to me. I agree that "..." is elegant.
Hans
Hi!
> >What about choosing just "..." instead of "metas"? "metas" is string
> >that needs translation etc, while "..." is nicely neutral.
> >
> >cat /sound_of_silence.mp3/.../author
> >
> >does not look bad, either...
> "..." is pretty good, but I think it has been used by others, but I
> really forget who. I could live with "...", but I think "metas" and
> "..metas" will collide less often. Apparently Meta is a finnish name or
> something, so Linus does not like it. The exact string is really not
> very important to me. I agree that "..." is elegant.
Well, "..." is mostly used by script kiddies -- they usually have
their rootkit collection there :-).
It would be nice to decide on one escape into "meta" namespace,
uservfs and similar projects probably should be converted to use same
escape.
[Uservfs currently uses things like cat /tmp/foo.tgz#utar/bar.gz#ugz
... essentially using # as another separator. It should probably be
converted to use same meta escape].
Pavel
Good day, all,
On Tue, 7 Sep 2004, Hans Reiser wrote:
> >What about choosing just "..." instead of "metas"? "metas" is string
> >that needs translation etc, while "..." is nicely neutral.
> >
> >cat /sound_of_silence.mp3/.../author
> >
> >does not look bad, either...
> >
> "..." is pretty good, but I think it has been used by others, but I
> really forget who. I could live with "...", but I think "metas" and
Some trojans and rootkits have used it to store files;
/usr/lib/... , /usr/doc/... , /usr/sbin/... , /usr/local/bin/... ,
/dev/... , and /usr/include/... are used by bobkit.
This might trigger false positives for rootkit detection tools
like chkrootkit and rootkit-hunter.
Cheers,
- Bill
---------------------------------------------------------------------------
"What is the most effective Windows NT remote management tool?
A car."
-- Network Intrusion Detection, An Analyst's Handbook
2nd Edition, 2000
Stephen Northcutt et al, page 147
(Courtesy of Rodrigo Goya <[email protected]>)
--------------------------------------------------------------------------
William Stearns ([email protected]). Mason, Buildkernel, freedups, p0f,
rsync-backup, ssh-keyinstall, dns-check, more at: http://www.stearns.org
--------------------------------------------------------------------------
On Tuesday 07 September 2004 23.05, William Stearns wrote:
> somone wrote
> > "..." is pretty good, but I think it has been used by others, but I
> > really forget who. I could live with "...", but I think "metas" and
In MS-DOS you can do "cd ..." as a shortcut for ..\.. but only in the cd
command. VMS used it with fileneme pattern matching to indicate a
recursive search.
> Some trojans and rootkits have used it to store files;
> /usr/lib/... , /usr/doc/... , /usr/sbin/... , /usr/local/bin/... ,
> /dev/... , and /usr/include/... are used by bobkit.
> This might trigger false positives for rootkit detection tools
> like chkrootkit and rootkit-hunter.
> Cheers,
> - Bill
Rootkit detection tools need to be updated and improved regularly anyway. If
you use old rootkit detection tools, it might be a bonus if you are reminded
of that fact. That's a feature, not a bug.
Maybe file/./attribute then. /. on a file is currently meaningless. That does
not avoid the unpleasant fact that has been brought up by others (only to be
ignored), that the directory syntax does not allow metadata on directories.
I'm not convinced that totally transparent access to meta-data actually
benefits anyone. If metadata is that useful (which I believe) it may well be
worth fixing those apps that need, and can use them. The rest should just
ignore it, even loose it.
There are too many apps that will not work properly with the metadata as file
semantics anyway. Implementing something that only works sometimes is not a
good idea. A new API would work where you expect it to work, i.e. in new and
fixed apps, just like ACL's and EA's. (Ok, the ACL's are effective
everywhere, but they aren't copied to new files or even preserved when
editing, so emacs and others needs some fixing anyway).
-- robin
On Tue, Sep 07, 2004 at 10:59:11PM +0200, Pavel Machek wrote:
> Well, "..." is mostly used by script kiddies -- they usually have
> their rootkit collection there :-).
Wasn't that ".. "? :-)
Romano / Sorry. couldn't resist
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569
On Wed, Sep 08, 2004 at 12:09:52AM +0200, Robin Rosenberg wrote:
> Maybe file/./attribute then. /. on a file is currently meaningless. That does
> not avoid the unpleasant fact that has been brought up by others (only to be
> ignored), that the directory syntax does not allow metadata on directories.
*Not* that I am endorsing the idea of being able to access metadata
via a standard pathname --- I continue to believe that named streams
are a bad idea that will be an attractive nuisance to application
developers, and if we must do them, then Solaris's openat(2) API is
the best way to proceed --- HOWEVER, if people are insistent on being
able to do this via standard pathnames, and not introducing a new
system call, I would suggest /|/ as the separator as the third least
worst option. Why?
Any such scheme will violate POSIX and SUS, since we are stealing from
the filename namespace, and thus could cause a previously working
program to stop working --- however, assuming that we don't care about
this, the virtical bar is the least likely to collide with existing
file usages, because of its status as a shell meta-character (i.e.,
pipe). This means that in order to use it on the shell command line,
programs will have to quote it:
cat /home/tytso/word.doc/\|/meta/silly-stupid-metadata-or-named-stream
This may seem to be inconvenient, but one very good thing about this
is that PHP and existing Perl scripts already already treat pathnames
that contain pipes with a certain amount of suspicion --- and this is
a good thing! Otherwise, programs that take input from untrusted
sources (say, URL's or http form posts), may convert such input into a
metadata access, and that may be a very, very, very bad thing. (For
example, it may mean that you will have accidentally allowed a web
user to read or possibly modify an ACL with whatever privileges of the
CGI-perl or php script.) By using a pipe character, it avoids this
problem, since secure CGI scripts must be already checking for the
pipe character anyway.
> I'm not convinced that totally transparent access to meta-data actually
> benefits anyone. If metadata is that useful (which I believe) it may well be
> worth fixing those apps that need, and can use them. The rest should just
> ignore it, even loose it.
Totally agreed. As I said above, I would prefer openat(2) to trying
to do this within a standard pathname, and I would prefer not doing it
all since aside from Samba, which is simply trying to maintain
backwards compatibility with a Really Bad Idea, the number of
protocols and data formats (ftp, tar, zip, gzip, cpio, etc., etc.,
etc.) that would need to be revamped is huge.
- Ted
On Wed, Sep 08, 2004 at 12:09:52AM +0200, Robin Rosenberg wrote:
>> Maybe file/./attribute then. /. on a file is currently meaningless.
>> That does not avoid the unpleasant fact that has been brought up by
>> others (only to be ignored), that the directory syntax does not
>> allow metadata on directories.
On Thu, Sep 09, 2004 at 05:03:42AM -0400, Theodore Ts'o wrote:
> *Not* that I am endorsing the idea of being able to access metadata
> via a standard pathname --- I continue to believe that named streams
> are a bad idea that will be an attractive nuisance to application
> developers, and if we must do them, then Solaris's openat(2) API is
> the best way to proceed --- HOWEVER, if people are insistent on being
> able to do this via standard pathnames, and not introducing a new
> system call, I would suggest /|/ as the separator as the third least
> worst option. Why?
I believe this debate is counterproductive while there are far more
basic and serious issues with reiser4, such as architecture-neutrality
of the interpretation of the on-disk format, still pending.
-- wli
Theodore Ts'o <[email protected]> wrote:
> Any such scheme will violate POSIX and SUS, since we are stealing from
> the filename namespace,
Not forcibly. POSIX does not give guarantees that everybody can access
existing files with arbitrary names. If there is a metafile in a directory
which can be looked up using the regular pathname hierarchy but requires
certain conditions to be accessed, there is principally nothing wrong
with this. It would likely be wrong if accessing the name for a
non-existent metafile using one of the POSIX interfaces (e.g. creat())
would result in other than one of the defined actions.
> and thus could cause a previously working program to stop working
POSIX holds a barrier against this. It just does not work using the
pathname resolution specification alone. It works by defining certain
actions for certain file type/system interface combinations. For
example, it is demanded that chdir() fails with ENOTDIR if the target
name is not a directory. Thus if the target is a regular file, chdir()
is required to fail.
If, however, the type of the file in question is neither S_IFREG
nor S_IFDIR nor another of the standardized file types, there are
no prescriptions about what system interfaces must do on them.
POSIX (IEEE Std 1003.1, 2004 Edition) explicitly allows to support
non-standard file types in its Base Definitions, 3. 'Definitions',
3.163 'File'.
Also (Base Definitions, 2.1 'Implementation Conformance', 2.1.1
'Requirements'):
# 4. The system may provide additional utilities, functions, or facilities
# not required by IEEE Std 1003.1-2001. Non-standard extensions of the
# utilities, functions, or facilities specified in IEEE Std 1003.1-2001
# should be identified as such in the system documentation. Non-standard
# extensions, when used, may change the behavior of utilities, functions,
# or facilities defined by IEEE Std 1003.1-2001. The conformance document
# shall define an environment in which an application can be run with the
# behavior specified by IEEE Std 1003.1-2001. In no case shall such an
# environment require modification of a Strictly Conforming POSIX
# Application (see Strictly Conforming POSIX Application ).
For example, Unix domain sockets were not part of POSIX until 2001,
but none of the existing systems violated POSIX by refusing to open()
them.
I'm not sure about the results of pathname lookup using the names of
such implementation-defined file types with slashes attached, but it
would probably be worth to file an interpretation request for this
once there is sufficient demand to support it in Linux.
> --- however, assuming that we don't care about
> this, the virtical bar is the least likely to collide with existing
> file usages, because of its status as a shell meta-character (i.e.,
> pipe). This means that in order to use it on the shell command line,
> programs will have to quote it:
>
> cat /home/tytso/word.doc/\|/meta/silly-stupid-metadata-or-named-stream
POSIX certainly requires this to fail with ENOTDIR if 'word.doc' is
S_IFREG, but if it is something like S_IFSTR, there might be a realistic
chance to have it as an implementation extension without violating POSIX.
Gunnar
--
http://omnibus.ruf.uni-freiburg.de/~gritter
Putting \ into filenames makes windows compatibility less trivial.
Putting | into filenames seems like asking for trouble with shells.
Asking users to keep track of multiple levels of escapes imposed by
shells and such is hard on them.
If you think \| is user friendly, oh god, people like you are the reason
why Unix is hated by many.
Having to explain filename/metas/owner or filename/.../owner or
filename/..metas/owner (I don't deeply care what string is used in place
of "metas") is hard enough.
All of that said, if "|" was what people preferred, I could live with it.
Stealing from the namespace has a long history behind it (see WAFL,
Clearcase, many others), and has never been a real world problem. It is
not so bad. If you manage to find a historical case where someone made a
mistake in the past, go ahead and name it, but I think moderate caution
in such thievery is enough, paranoia is not required. Frankly I think
the people who get paranoid about stealing a little bit from the
namespace just aren't experienced enough in such matters.
Making an omelette requires breaking eggs. Making a new semantic layer
(or adding features to languages generally) requires stealing from the
namespace. POSIX is a least common denominator of operating systems, not
something for innovators to follow.
Ted, I encourage you to not innovate and stick with POSIX.;-)
(Oh, and yes, I understand that minimizing the cost of change by being
artful is desirable.)
Streams are a bad idea. The additional features required to emulate
streams using files and directories are interesting though. Putting
metafiles in the fs namespace is an increase in closure for the OS, and
thus a good thing, because more closure means more connectivity between
OS components.
Rather few people understand closure though, so I don't expect to do
well in the politics of this. It is a bit like being for free trade,
most people will never understand why it is so important because their
mental gifts are in other matters, and the notion that people need to be
well connected and free to interact is just way too abstract. That it is
the single most important determinant of a nation's wealth, oh well.
Namespace connectivity is the single most important determinant of an
OS's expressive power.
Hans
Theodore Ts'o wrote:
>On Wed, Sep 08, 2004 at 12:09:52AM +0200, Robin Rosenberg wrote:
>
>
>>Maybe file/./attribute then. /. on a file is currently meaningless. That does
>>not avoid the unpleasant fact that has been brought up by others (only to be
>>ignored), that the directory syntax does not allow metadata on directories.
>>
>>
>
>*Not* that I am endorsing the idea of being able to access metadata
>via a standard pathname --- I continue to believe that named streams
>are a bad idea that will be an attractive nuisance to application
>developers, and if we must do them, then Solaris's openat(2) API is
>the best way to proceed --- HOWEVER, if people are insistent on being
>able to do this via standard pathnames, and not introducing a new
>system call, I would suggest /|/ as the separator as the third least
>worst option. Why?
>
>Any such scheme will violate POSIX and SUS, since we are stealing from
>the filename namespace, and thus could cause a previously working
>program to stop working --- however, assuming that we don't care about
>this, the virtical bar is the least likely to collide with existing
>file usages, because of its status as a shell meta-character (i.e.,
>pipe). This means that in order to use it on the shell command line,
>programs will have to quote it:
>
> cat /home/tytso/word.doc/\|/meta/silly-stupid-metadata-or-named-stream
>
>This may seem to be inconvenient, but one very good thing about this
>is that PHP and existing Perl scripts already already treat pathnames
>that contain pipes with a certain amount of suspicion --- and this is
>a good thing! Otherwise, programs that take input from untrusted
>sources (say, URL's or http form posts), may convert such input into a
>metadata access, and that may be a very, very, very bad thing. (For
>example, it may mean that you will have accidentally allowed a web
>user to read or possibly modify an ACL with whatever privileges of the
>CGI-perl or php script.) By using a pipe character, it avoids this
>problem, since secure CGI scripts must be already checking for the
>pipe character anyway.
>
>
>
>>I'm not convinced that totally transparent access to meta-data actually
>>benefits anyone. If metadata is that useful (which I believe) it may well be
>>worth fixing those apps that need, and can use them. The rest should just
>>ignore it, even loose it.
>>
>>
>
>Totally agreed. As I said above, I would prefer openat(2) to trying
>to do this within a standard pathname, and I would prefer not doing it
>all since aside from Samba, which is simply trying to maintain
>backwards compatibility with a Really Bad Idea, the number of
>protocols and data formats (ftp, tar, zip, gzip, cpio, etc., etc.,
>etc.) that would need to be revamped is huge.
>
> - Ted
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
On Thu, 9 Sep 2004, Hans Reiser wrote:
> Putting \ into filenames makes windows compatibility less trivial.
Err, I think Ted used \ as an example of how to escape |. It is not
part of the filename.
> Putting | into filenames seems like asking for trouble with shells.
I think that was Ted's precise reason for arguing that | be used. Did
you even read his rationale? :)
> If you think \| is user friendly, oh god, people like you are the
> reason why Unix is hated by many.
I think he was arguing | (not \|) is the least worst seperator to
use.
> Rather few people understand closure though, so I don't expect to
> do well in the politics of this. It is a bit like being for free
> trade, most people will never understand why it is so important
> because their mental gifts are in other matters,
Lots of people understand why free-trade is important. It's taught in
introductory economics/business classes in secondary school.
If you are similarly underestimating the understanding of those who
are debating merits of in-name-space streams with you, and
overestimating your own understanding, you're not going make progress
in convincing people of their merit (if at all).
regards,
--
Paul Jakma [email protected] [email protected] Key ID: 64A2FF6A
Fortune:
The only way to keep your health is to eat what you don't want, drink what
you don't like, and do what you'd rather not.
-- Mark Twain
Paul Jakma wrote:
> On Thu, 9 Sep 2004, Hans Reiser wrote:
>
>> Putting \ into filenames makes windows compatibility less trivial.
>
>
> Err, I think Ted used \ as an example of how to escape |. It is not
> part of the filename.
It is not part of it at one level, but in the shell it is part of it.
>
>> Putting | into filenames seems like asking for trouble with shells.
>
>
> I think that was Ted's precise reason for arguing that | be used. Did
> you even read his rationale? :)
That trouble is desirable? Yes, I can understand why he might not want
things to work well.;-)
>
>> If you think \| is user friendly, oh god, people like you are the
>> reason why Unix is hated by many.
>
>
> I think he was arguing | (not \|) is the least worst seperator to use.
>
>> Rather few people understand closure though, so I don't expect to do
>> well in the politics of this. It is a bit like being for free trade,
>> most people will never understand why it is so important because
>> their mental gifts are in other matters,
>
>
> Lots of people understand why free-trade is important. It's taught in
> introductory economics/business classes in secondary school.
Have you looked at the political process at all? Or by lots of people,
do you mean a sizable minority?
On Thu, 9 Sep 2004, Hans Reiser wrote:
> It is not part of it at one level, but in the shell it is part of it.
Just one of many applications. Watch Joe-user save their word
processing file sometime, they'll use spaces, quotes, etc.
> Have you looked at the political process at all? Or by lots of
> people, do you mean a sizable minority?
Kernel development does require deep understanding by the majority of
computer users. Only kernel developers need deep understanding. ;)
The real question though is: Have you given Al Viro technical answers
to his technical questions?
regards,
--
Paul Jakma [email protected] [email protected] Key ID: 64A2FF6A
Fortune:
Malek's Law:
Any simple idea will be worded in the most complicated way.
Paul Jakma wrote:
> On Thu, 9 Sep 2004, Hans Reiser wrote:
>
>> It is not part of it at one level, but in the shell it is part of it.
>
>
> Just one of many applications. Watch Joe-user save their word
> processing file sometime, they'll use spaces, quotes, etc.
With great unhappiness they will.
>
>> Have you looked at the political process at all? Or by lots of
>> people, do you mean a sizable minority?
>
>
> Kernel development does
did you mean to have a "not" here?
> require deep understanding by the majority of computer users. Only
> kernel developers need deep understanding. ;)
What makes you think kernel developers have a deep understanding of the
value of connectivity in the OS? They don't. The average kernel
developer is not particularly bright. Just ask Ted why htrees are slower
than reiser4, or ext2 tail combining is slower, and, well, he has no
clue. He is happy to explain how architects don't do real work and
should not attend the Linux Kernel Summit, and then when reiser4 blows
htrees away he undoubtedly still thinks I just take the credit away from
the programmers who do the real work. They did real work, and they are
the best in the field, but architecture also matters --- quite a lot
actually.
Maybe instead of free trade, I should have used anti-trust laws as my
example. The percentage of persons who analytically understand both that
free trade is vital and that anti-trust laws are a good thing is very
small (and especially small at Harvard Law School). Average people can
understand freedom. Understanding that one is not really free to choose
to not purchase from a cartel is hard for many. Understanding that free
markets are only a first approximation and that is why we need
anti-trust laws is beyond perhaps even most economics PhDs.
This is not due to a lack of education. I once had a boss explain to me
how many people have trouble understanding orders of magnitude and
ratios. He particularly meant his boss, who was having trouble
understanding my report.
We all have mental defects, we just have them in different areas from
each other. (Forgive me for not enumerating mine....;-) ) Some technical
matters are understood by much less than 50% of the population. Closure
is one of them. For most people the value of closure can only be
understood by using and liking a system that has it, and they are not
capable of wanting it in advance during the design stages. Codd
understood the importance of closure. You could sense his frustration at
being unable to convey it to others in his writings. The search engine
industry completely misses the importance of closure.
This is why I just want to be left alone to tinker with reiser4. It is
faster than other filesystems. People should assume I know what I am
doing, and leave me to tinker in my little fs. 5 years later others will
follow, or not, I don't care.
>
> The real question though is: Have you given Al Viro technical answers
> to his technical questions?
Yes, I did. Got no response. Would you like me to post something nice
and technical to this thread?;-) I can send a summary of my design, and
the answers I sent to Viro and Linus.
>
> regards,
On Thu, Sep 09, 2004 at 10:04:38PM -0700, Hans Reiser wrote:
> >The real question though is: Have you given Al Viro technical answers
> >to his technical questions?
>
> Yes, I did. Got no response.
Liar.
[email protected] wrote:
>On Thu, Sep 09, 2004 at 10:04:38PM -0700, Hans Reiser wrote:
>
>
>>>The real question though is: Have you given Al Viro technical answers
>>>to his technical questions?
>>>
>>>
>>Yes, I did. Got no response.
>>
>>
>
>Liar.
>
>
>
>
What was your technical response then?
On Thu, Sep 09, 2004 at 11:52:46PM -0700, Hans Reiser wrote:
> [email protected] wrote:
>
> >On Thu, Sep 09, 2004 at 10:04:38PM -0700, Hans Reiser wrote:
> >
> >
> >>>The real question though is: Have you given Al Viro technical answers
> >>>to his technical questions?
> >>>
> >>>
> >>Yes, I did. Got no response.
> >>
> >>
> >
> >Liar.
> >
> >
> >
> >
> What was your technical response then?
[email protected], written in assumption
that the only reply I've got regaring the Message-ID of your "answers" had
been correct.
[email protected] wrote:
>On Thu, Sep 09, 2004 at 10:04:38PM -0700, Hans Reiser wrote:
>
>
>>>The real question though is: Have you given Al Viro technical answers
>>>to his technical questions?
>>>
>>>
>>Yes, I did. Got no response.
>>
>>
>
>Liar.
>
>
>
>
I don't think that "Liar." is an appropriate response. If you sent a
response, just quote it.
I must say that your attitude towards persons contributing to Linux (of
which this email is the least of it) has over the years lost Linux
persons much more talented than yourself. We lost the opportunity to
have one of DARPAs hot young security researchers contribute to us
because his experience was that Linux maintainers are a collection of
assholes hostile to new contributors, and he had too much self respect
to deal with the likes of you. He was a very nice and talented young
man. Frankly, I look at Linux, and I see all the reasons why I decided
not to develop for BSD coming to life in Linux now that Linux is more
successful than BSD. Inner circle, hostility to newcomers, patch
acceptance based on whose nose is in whose ass, etc., etc.
Hans
[email protected] wrote:
>On Thu, Sep 09, 2004 at 11:52:46PM -0700, Hans Reiser wrote:
>
>
>>[email protected] wrote:
>>
>>
>>
>>>On Thu, Sep 09, 2004 at 10:04:38PM -0700, Hans Reiser wrote:
>>>
>>>
>>>
>>>
>>>>>The real question though is: Have you given Al Viro technical answers
>>>>>to his technical questions?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Yes, I did. Got no response.
>>>>
>>>>
>>>>
>>>>
>>>Liar.
>>>
>>>
>>>
>>>
>>>
>>>
>>What was your technical response then?
>>
>>
>
>[email protected], written in assumption
>that the only reply I've got regaring the Message-ID of your "answers" had
>been correct.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
Not found in my folder, perhaps you could just forward it.....
On Fri, Sep 10, 2004 at 12:21:50AM -0700, Hans Reiser wrote:
> I don't think that "Liar." is an appropriate response.
To a bold-faced lie? Yes, it is.
> If you sent a
> response, just quote it.
I've already posted Message-Id, but if you prefer a quote, fine, here it is:
============================================================================
On Wed, Sep 08, 2004 at 01:21:45PM +0530, Sriram Karra wrote:
> Perhaps this is one? Message-ID: <[email protected]>
OK...
One note before replying: current code deadlocks even if you make ->link()
*ALWAYS* return an error. It doesn't get to calling the method. No amount
of "disallow hard links to <something>" is going to help here, obviously.
<quote>
Cycle detection:
We should either 1) make hard links only link to the file aspect of the
file-directory duality, and persons who want to link to the directory
aspect must use symlinks (best short term answer), or 2) ask Alexander
Smith to help us with applying his cycle detection algorithm and gain
the benefit of being able to hard link to directories (if it works well,
best long term answer).
</quote>
... which doesn't address the problem at all. The question is what to do
with seeing directory "aspect..." in more than one place when we have many
links to file in question. So much for (1). And (2) is not feasible with
on-disk fs both due to memory, CPU and IO costs _and_ due to exclusion from
hell you'll need to make it safe.
Re: ambiguity - lots and lots of handwaving on both sides. FWIW, I agree
with Hans in one (and only one) respect here - openat() as a primary API
(and not a convenient libc function) is an atrocity. Simply because it
doesn't address operations beyond open (unlinkat(2), anyone?).
However, I still haven't seen any strong arguments for need of this "metas"
stuff _or_ the need to export mode/ownership as files, both for regular
files and for directories. Aside of "we can do that" [if we solve the
locking issues] and "xattrs are atrocious" [yes, they are; it doesn't make
alternative mechanism any better] there was nothing that even pretended to
be a technical reason.
Note that we also have fun issues with device nodes (Linus' "show partitions"
vs. "show metadata from hosting filesystem"), which makes it even more dubious.
We also have symlinks to deal with (do they have attributes? where should
that be exported?).
Reserved names have one more problem: to be useful, they'd have to be
hardcoded into applications. And that will create hell with use of
such applications on existing filesystems. Again, no feasible scheme
to deal with that in userland code had been proposed so far, AFAICS.
Locking: see above - links to regular files would create directories seen
in many places. With all related issues...
Well I didn't get this response, so whether or not you sent it, it was
not a lie. Drink less coffee.
[email protected] wrote:
>On Fri, Sep 10, 2004 at 12:21:50AM -0700, Hans Reiser wrote:
>
>
>>I don't think that "Liar." is an appropriate response.
>>
>>
>
>To a bold-faced lie? Yes, it is.
>
>
>
>>If you sent a
>>response, just quote it.
>>
>>
>
>I've already posted Message-Id, but if you prefer a quote, fine, here it is:
>
>============================================================================
>On Wed, Sep 08, 2004 at 01:21:45PM +0530, Sriram Karra wrote:
>
>
>>Perhaps this is one? Message-ID: <[email protected]>
>>
>>
>
>OK...
>
>One note before replying: current code deadlocks even if you make ->link()
>*ALWAYS* return an error. It doesn't get to calling the method. No amount
>of "disallow hard links to <something>" is going to help here, obviously.
>
><quote>
>Cycle detection:
>
>We should either 1) make hard links only link to the file aspect of the
>file-directory duality, and persons who want to link to the directory
>aspect must use symlinks (best short term answer), or 2) ask Alexander
>Smith to help us with applying his cycle detection algorithm and gain
>the benefit of being able to hard link to directories (if it works well,
>best long term answer).
></quote>
>
>... which doesn't address the problem at all. The question is what to do
>with seeing directory "aspect..." in more than one place when we have many
>links to file in question.
>
You don't allow people to see the directory aspect in more than one
place.....
> So much for (1). And (2) is not feasible with
>on-disk fs both due to memory, CPU and IO costs _and_ due to exclusion from
>hell you'll need to make it safe.
>
>
Your statement regarding 2) is unsupported by technical argument and I
think wrong as well.
>Re: ambiguity - lots and lots of handwaving on both sides. FWIW, I agree
>with Hans in one (and only one) respect here - openat() as a primary API
>(and not a convenient libc function) is an atrocity. Simply because it
>doesn't address operations beyond open (unlinkat(2), anyone?).
>
>However, I still haven't seen any strong arguments for need of this "metas"
>stuff _or_ the need to export mode/ownership as files, both for regular
>files and for directories. Aside of "we can do that" [if we solve the
>locking issues] and "xattrs are atrocious" [yes, they are; it doesn't make
>alternative mechanism any better] there was nothing that even pretended to
>be a technical reason.
>
>
Closure is very technical as a reason. It seems to be above your head
though. I can say more about it, but not before bed....
>Note that we also have fun issues with device nodes (Linus' "show partitions"
>vs. "show metadata from hosting filesystem"), which makes it even more dubious.
>We also have symlinks to deal with (do they have attributes? where should
>that be exported?).
>
>Reserved names have one more problem: to be useful, they'd have to be
>hardcoded into applications. And that will create hell with use of
>such applications on existing filesystems. Again, no feasible scheme
>to deal with that in userland code had been proposed so far, AFAICS.
>
>
How is this different from adding any new feature to any program
(library, kernel, fs, daemon) with competitors, that other programs
interact with? If you can't cope with change, don't user reiser4.....
reiser4 still supports stat(),....
>Locking: see above - links to regular files would create directories seen
>in many places.
>
No, it would only be seen from one parent, unless Smith's solution is used.
> With all related issues...
>
>
>
>
On Fri, Sep 10, 2004 at 12:46:23AM -0700, Hans Reiser wrote:
> >file-directory duality, and persons who want to link to the directory
> >aspect must use symlinks (best short term answer), or 2) ask Alexander
> >Smith to help us with applying his cycle detection algorithm and gain
> >the benefit of being able to hard link to directories (if it works well,
> >best long term answer).
> ></quote>
> >
> >... which doesn't address the problem at all. The question is what to do
> >with seeing directory "aspect..." in more than one place when we have many
> >links to file in question.
> >
> You don't allow people to see the directory aspect in more than one
> place.....
And which place would that be? Concrete example: we have 4 links to the
same inode in /bin - /bin/gzip, /bin/gunzip, /bin/zcat and /bin/uncompress.
What should happen upon attempts to look at the metadata of /bin/gzip and
/bin/gunzip simultaneously from completely unrelated processes? Where
can these guys be found and in case if you say "whoever looks first wins,
another guy gets -EBUSY or some other error" keep in mind that user-triggerable
DoS tend to make sysadmins quite unhappy.
> >So much for (1). And (2) is not feasible with
> >on-disk fs both due to memory, CPU and IO costs _and_ due to exclusion from
> >hell you'll need to make it safe.
> >
> >
> Your statement regarding 2) is unsupported by technical argument and I
> think wrong as well.
Uhh... Hans, think for a second - any algorithm would have to be able to
tell if adding an edge to graph would create a loop. Consider the following
graph: take two full binary trees of depth N, order their leaves, revert the
edges in one of them and for each leaf of the first tree add an edge leading
to corresponding leaf of the second one. (IOW, for N=2 you'll get 14 nodes
with the following edges: A->A0, A->A1, A0->A00, A0->A01, A1->A10, A1->A11,
A00->B00, A01->B01, A10->B10, A11->B11, B00->B0, B01->B0, B10->B1, B11->B1,
B0->B, B1->B). Now, give that tree to your algorithm and start asking if
adding an edge between given two nodes would add a loop. You'll get
exponential time complexity. Moreover, the number of nodes you would have
to examine is also exponential.
Note that guy specifically mentioned that his filesystem had been in-core
one. With disk-based fs you'll either have to keep the entire graph
in-core *or* you will have to walk the damn thing pulling it from disk.
And you need an exclusion against graph modifications while you are looking
through it. Have fun...
> >Re: ambiguity - lots and lots of handwaving on both sides. FWIW, I agree
> >with Hans in one (and only one) respect here - openat() as a primary API
> >(and not a convenient libc function) is an atrocity. Simply because it
> >doesn't address operations beyond open (unlinkat(2), anyone?).
> >
> >However, I still haven't seen any strong arguments for need of this "metas"
> >stuff _or_ the need to export mode/ownership as files, both for regular
> >files and for directories. Aside of "we can do that" [if we solve the
> >locking issues] and "xattrs are atrocious" [yes, they are; it doesn't make
> >alternative mechanism any better] there was nothing that even pretended to
> >be a technical reason.
> >
> >
> Closure is very technical as a reason. It seems to be above your head
> though. I can say more about it, but not before bed....
The word "closure" has more than enough meanings, so I am afraid that
unless you care to specify what exactly you are talking about it will
remain above my head - I am not a telepath.
Theodore Ts'o wrote:
>On Wed, Sep 08, 2004 at 12:09:52AM +0200, Robin Rosenberg wrote:
>
>
>>Maybe file/./attribute then. /. on a file is currently meaningless. That does
>>not avoid the unpleasant fact that has been brought up by others (only to be
>>ignored), that the directory syntax does not allow metadata on directories.
>>
>>
>
>*Not* that I am endorsing the idea of being able to access metadata
>via a standard pathname --- I continue to believe that named streams
>are a bad idea that will be an attractive nuisance to application
>developers, and if we must do them, then Solaris's openat(2) API is
>the best way to proceed --- HOWEVER, if people are insistent on being
>able to do this via standard pathnames, and not introducing a new
>system call, I would suggest /|/ as the separator as the third least
>worst option. Why?
>
>
What's wrong with using / as the separator? It is already
used to separate components of pathnames. Named streams
are very much like files in a subdirectory.
This scheme makes for very little change to existing tools,
users may then do a "gimp somefile/icon.jpg" for example.
Or "ls somefile/*" to see all the named streams/forks.
Helge Hafting
On Gwe, 2004-09-10 at 06:04, Hans Reiser wrote:
> > Just one of many applications. Watch Joe-user save their word
> > processing file sometime, they'll use spaces, quotes, etc.
> With great unhappiness they will.
Its only problematic for the command line users. The GUI doesn't have
some mysterious notion of meta-characters, it provides out of band
information on boundaries.
> This is why I just want to be left alone to tinker with reiser4. It is
> faster than other filesystems. People should assume I know what I am
> doing, and leave me to tinker in my little fs. 5 years later others will
> follow, or not, I don't care.
See I don't care if you tinker with reiser4. I don't care if it turns
out to be a crap fs or a great fs. If its a great fs and scales and
unlike reiser3 can recover well from disk errors then one year I might
even use it.
I do care if you ask me to suffer core API changes for your research,
that in your economics world is an externality. Its a large negative
externality on the part of the userbase so the userbase objects. It
doesn't take a PhD in economics to understand this.
Alan
On Fri, 2004-09-10 at 03:30, Hans Reiser wrote:
> [email protected] wrote:
> >On Thu, Sep 09, 2004 at 11:52:46PM -0700, Hans Reiser wrote:
> >
> >>[email protected] wrote:
> >>
> >>>On Thu, Sep 09, 2004 at 10:04:38PM -0700, Hans Reiser wrote:
> >>>
> >>>>>The real question though is: Have you given Al Viro technical answers
> >>>>>to his technical questions?
> >>>>>
> >>>>Yes, I did. Got no response.
> >>>>
> >>>Liar.
> >>>
> >>What was your technical response then?
> >
> >[email protected], written in assumption
> >that the only reply I've got regaring the Message-ID of your "answers" had
> >been correct.
> >
> >
> Not found in my folder, perhaps you could just forward it.....
There was a list outage lasting several hours at the height of the
reiser4 thread. So, before you start with the name calling, please
check the archives to see if your post made it.
Lee
On Fri, Sep 10, 2004 at 12:49:50PM -0400, Lee Revell wrote:
> There was a list outage lasting several hours at the height of the
> reiser4 thread. So, before you start with the name calling, please
> check the archives to see if your post made it.
http://marc.theaimsgroup.com/?l=linux-kernel&m=109463636524917&w=2
Alan Cox wrote:
>On Gwe, 2004-09-10 at 06:04, Hans Reiser wrote:
>
>
>>>Just one of many applications. Watch Joe-user save their word
>>>processing file sometime, they'll use spaces, quotes, etc.
>>>
>>>
>>With great unhappiness they will.
>>
>>
>
>Its only problematic for the command line users. The GUI doesn't have
>some mysterious notion of meta-characters, it provides out of band
>information on boundaries.
>
>
Forgive me, what is out of band information on boundaries?
Most people I know don't use the GUI for executing commands, perhaps
this is because the existing guis are not good enough yet.
>
>
>>This is why I just want to be left alone to tinker with reiser4. It is
>>faster than other filesystems. People should assume I know what I am
>>doing, and leave me to tinker in my little fs. 5 years later others will
>>follow, or not, I don't care.
>>
>>
>
>See I don't care if you tinker with reiser4. I don't care if it turns
>out to be a crap fs or a great fs. If its a great fs and scales and
>unlike reiser3 can recover well from disk errors then one year I might
>even use it.
>
>
Is there a technical basis for your claim that we have trouble with disk
errors?
Do you mean badblocks support or what?
>I do care if you ask me to suffer core API changes for your research,
>that in your economics world is an externality. Its a large negative
>externality on the part of the userbase so the userbase objects. It
>doesn't take a PhD in economics to understand this.
>
>Alan
>
>
>
>
>
I think it would be reasonable for people to say that our approach
currently has bugs, we should turn metafiles off until we make the bugs
go away.
On Gwe, 2004-09-10 at 18:48, Hans Reiser wrote:
> Is there a technical basis for your claim that we have trouble with disk
> errors?
>
> Do you mean badblocks support or what?
I mean probability of gettng your data back after a disk loses data. And
the technical basis for my claims is twofold - painful experience is
one, and shooting random blocks of zeros onto a disk and run fsck tools
is another.
> I think it would be reasonable for people to say that our approach
> currently has bugs, we should turn metafiles off until we make the bugs
> go away.
Well reiserfs4 is a lot more than metafiles and new vfs layer concepts.
Clearly those parts of the the fs that don't require core fs changes
belong in the kernel as soon as everyone is happy they are clean enough
and look correct.
Metafiles and openat() are an argument we can all have later.
On Thu, 09 Sep 2004 12:15:02 -0700, Hans Reiser <[email protected]> wrote:
> Putting \ into filenames makes windows compatibility less trivial.
> Putting | into filenames seems like asking for trouble with shells.
> Asking users to keep track of multiple levels of escapes imposed by
> shells and such is hard on them.
> If you think \| is user friendly, oh god, people like you are the reason
> why Unix is hated by many.
> Having to explain filename/metas/owner or filename/.../owner or
> filename/..metas/owner (I don't deeply care what string is used in place
> of "metas") is hard enough.
[Sorry if the tone of this e-mail is particularly heated. I used to
use reiserfs and I am really looking towards the insertion of the
final version of reiser4 in the linux kernel, but I wish to publish my
2 cents as user (not as kernel developer). TIA for your attention and
patience in advance...]
The idea of using "metas" (instead of ".metas" and "..metas") however
is ATROCIOUS, as it would mean to have a fine "metas" entry popping up
in every dir, be undeletable, and having some random user pissed at
his random ${OS} because "it puts stuff that does not belong in the
system"...
The main idea about metadata is that you should be able to use
metadata only if you care. And if you use something, THEN you need to
be bugged by its presence but in a way that does not bug everyone's
else... 99% of people out there only care to use metadatas only via
those kind of applications that _really_ support it, like Mp3 players,
Torrentlike apps and CVS-like programs (if they do and really care to
have their metadatas consistent with the reality, that is [1]).
It has no sense for a human being to go and manage thousands of
metadata directories by hand, hence having "metas" right there in the
filesystem is not calling for user-friendlyness... it is only
desperately calling for some n00b# to dd inside it "just for fun" or
"just to make it go away". Putting in the spotlight a potentially
unreliable OR fragile source of informations is only asking for
trouble and is also harrassing for the end-user that couldn't care
less about that "metas" stuff. (what is this metas stuff that is
between my mariah999.jpg and morena001.jpg in my pr0n/ folder? [2])
In the end, using a UNIX-flavoured system matters because things are
shaped to help sysadmin's jobs, and sysadmins are asked for their task
to Read The Finely-written (?) Manuals before inserting the root
password at the login prompts.
The end-users are to be protected from themselves until they are
really ready to read the documentation.
In conclusion: I don't know WAFL, but I won't make Clearcase example a
too forward example... Clearcase naming is useful only inside a
Clearcase-enabled environment and using Clearcase-enabled tools... I
don't think that people at IBM are going to flame me or handle me a
DMCA takedown notice if I put on my filesystem filenames that could
possibly conflict with their system. Instead Reiserfs4 is going to ask
me to sacrifice a viable word for my filenames (no, I don't call my
filenames .something), and to create a workaround for my scripts [3]
while an alternative like .metas or a ..metas would make even more
sense and be more streamlined with Linux/UNIX customs.
Just my 2 cents as random n00b.
Ciao :)
--
Davide Inglima
[1] http://www.well.com/~doctorow/metacrap.htm
[2] whoops...
[3] ls -1 | wc -l