RE: [9fans] ls, rc question

RE: [9fans] ls, rc question

[Tiit Lankots]

As Rob said, the current beahaviour is good in the sense that it's
simple and predictable. However, it would maybe also be nice to glob
match _names_, not paths. Right now, I fail to see, how it would 
break something, e.g. acme.

Re: [9fans] ls, rc question

[Charles Forsyth]

>>By "this point", I meant the observation that bind(..MAFTER|MBEFORE)
>>doesn't produce a union in the mathematical sense, but a list.  If
>>someone finds a reference anywhere in the mathematical literature to a
>>union operator which is non-commutative, I will happily retract my claim.

a non-commutative union does occur when working with certain constructions
on trees (funnily enough) [for much the same reason that addition and
multiplication aren't always commutative] but i haven't got a good reference.

Re: [9fans] ls, rc question

[Richard Miller]

I said:
> Sorry, David is correct on this point.

<boyd@insultant.net> said:
> BULLSHIT

By "this point", I meant the observation that bind(..MAFTER|MBEFORE)
doesn't produce a union in the mathematical sense, but a list.  If
someone finds a reference anywhere in the mathematical literature to a
union operator which is non-commutative, I will happily retract my claim.

<geoff@collyer.net> said:
> Mathematics is a powerful tool, but not appropriate for solving all
> problems. ...

Agreed.  ("A mathematician, a physicist, and an engineer checked into
a hotel one night ... " No, you've all heard that one already.)

But when we use mathematical metaphors to explain the behaviour of
engineering artefacts, choosing a not-quite-right metaphor can
cause confusion.  As in this case.

-- Richard

Re: [9fans] ls, rc question

[Charles Forsyth]

>>duplicate names.  So the accurate mathematical model is a sequence
>>(aka list), and bind is not union of sets or bags, but append of

you're right.  i was trying too hard to justify the term `union' (or not hard enough,
depending on how you look at it).  i've seen it argued elsewhere that union
directories ought to have used another term, for much these reasons.
still, they seem to work whatever you call them.

Re: [9fans] ls, rc question

[Geoff Collyer]

Mathematics is a powerful tool, but not appropriate for solving all
problems.  I think that the things that made Unix and now Plan 9 most
appealing are matters of judgement and taste.  Obviously hard
technical work has also gone into those systems, but I don't believe
that that is enough to produce a compelling operating system.  I
wouldn't want to try to justify the creation or use of pipes or 9p or
namespaces or user-mode file servers solely using mathematics.

Re: [9fans] ls, rc question

[Richard Miller]

> BULLSHIT

A soundly reasoned mathematical argument, very impressive.

Re: [9fans] ls, rc question

[boyd, rounin]

> Sorry, David is correct on this point.

BULLSHIT

hiding things will only wind up in nasty suprises, further down the track
...

Re: [9fans] ls, rc question

[Richard Miller]

>>>The thing is, reads from a union directory do in fact give you the union. 
> 
> i think the argument is provoked by the assumption that it's a union of sets, preventing duplicates,
> but the system happens to work with bags, not sets, where union can (must) allow duplicates.

Sorry, David is correct on this point.  Sets and bags are both
unordered, and union is therefore commutative.  But directories are
ordered -- the ordering is essential to resolve the ambiguity of
duplicate names.  So the accurate mathematical model is a sequence
(aka list), and bind is not union of sets or bags, but append of
sequences -- a non-commutative operator, hence the need to specify
MBEFORE or MAFTER.

-- Richard

Re: [9fans] ls, rc question

[Charles Forsyth]

>>The thing is, reads from a union directory do in fact give you the union. 

i think the argument is provoked by the assumption that it's a union of sets, preventing duplicates,
but the system happens to work with bags, not sets, where union can (must) allow duplicates.
i'd agree it's sometimes annoying but it's both explicable and understandable,
and (i'd say) not theoretically indefensible.   at a practical level, making the duplicates
visible happens to make it easy to illustrate (bind a directory to itself:
look, everything in it is duplicated).

Re: [9fans] ls, rc question

[Micah Stetson]

> Do you think that rc globbing returning as many identical words
> as there are directory entries with the same name is in any
> way useful too?

Of course!  Let's suppose you have a multipage document
that you want to print multiple copies of, but you want
all the copies of a single page to print together.  Well,
just split the document into one file per page and then
run 'bind -a . .' followed by 'lp *'.  How cool is that?
This example should make it clear that lp -c is a violation
of the tools approach.

Micah

(For the more serious among us, this is all 'tongue in cheek'.)

Re: [9fans] ls, rc question

[boyd, rounin]

yeah, you could get yourself into a real bind ...

Re: [9fans] ls, rc question

[ron minnich]

Well, I guess it's confusing the way some union stuff works, but once you
start trying to do things with unions to make them less weird, it can get
ugly fast, see this from a bsd list:

"  Perhaps one situation would be, modify a lower-layer file so that the
modified file now exists in the upper layer, with the original still in
the lower layer.  Then try to delete the file. The upper-layer version
will be deleted, but we don't want the lower-layer version to now start
showing up, because we 'delete'd it.  We also don't want to delete the
lower-layer version, because it's a union filesystem, and that's one of
the features of a union mount -- the lower layer is not allowed to change
(much).  So, cover up the lower-layer version with 'whiteout' in the upper
layer so that it becomes not visible to the union-mount, but still exists
via non-union-mount access. "

Also see rm -W on bsd. 

Or how about this: "Running find(1) over a union tree has the side-effect 
of creating a tree of shadow directories in the upper layer."

BSD does do this: "In this example, /b is layered over an empty directory
/mnt, then /a is layered over the new view of /mnt.  Duplicate names are
suppressed so that only one occurrence of `x' (and also `.' and `..')  
will appear." (see
http://www.usenix.org/publications/library/proceedings/neworl/full_papers/mckusick.a)

Seems once you start to try to get smart there's no end to it.

I've had it put to me that union mounts would so hopelessly confuse users
that they can't be used. The first time I showed them to a quite smart CS
person she blanched a bit -- "how can anybody use that given you don't
really know what those two files are?" And here I was showing it off --
"see how you can build kernels outside the kernel tree". The only reaction
was: "yeah but having two pccpu files show up in ls is hopelessly
confusing. " I had to disagree :-)

The thing is, reads from a union directory do in fact give you the union. 
But what would you do for stat etc? I'm not sure you could do much 
different that has been done without really making the kernel pretty 
dirty (see above).

ron

Re: [9fans] ls, rc question

[boyd, rounin]

> From: "David Tolpin" <dvd@davidashen.net>

got a problem with simple graphs?

Re: [9fans] ls, rc question

[David Tolpin]

> if you want, you can think of this as a bug in read(2):

In fact, I think both read(2) and stat(2) are OK.

The bug (or just inexact wording in the manual for read(2)).

But then either globbing should work differently (and looking
at the code in rc, i think it is easy to make it work as with union);
or the manual for rc should be changed as well.

Besides, then why bind(,,MBEFORE|MAFTER) is said to create a 'union' 
then? It is very confusing too. It does not. It creates a list, 
and name-oriented calls ([a-z]*stat, open) are restricted to only retrieve 
the first element in the list. Other calls can still traverse the list.


> that it doesn't really break much (you've found about
> all of it!) to leave it as is, and that it results in things
> like /bin/ls giving interesting information about the union.

Do you think that rc globbing returning as many identical words
as there are directory entries with the same name is in any
way useful too?

Re: [9fans] ls, rc question

[rsc]

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

if you want, you can think of this as a bug in read(2):
if a file is covered up, it should be completely hidden.
it turns out that actually implementing this is quite hard,
that it doesn't really break much (you've found about
all of it!) to leave it as is, and that it results in things
like /bin/ls giving interesting information about the union.

[-- Attachment #2: Type: message/rfc822, Size: 3410 bytes --]

From: David Tolpin <dvd@davidashen.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ls, rc question
Date: Fri, 19 Mar 2004 03:00:51 +0400 (AMT)
Message-ID: <200403182300.i2IN0p5T095713@adat.davidashen.net>


I am not asking why there are two file names in the directory listing. I understand it.

I think that behaviours of rc and ls are confusing. I would either expect rc's globbing
to only match one path name, or ls to display all files.

man rc says 'A pattern is replaced by a list of arguments, one
for each path name matched'. Not for each directory entry. For
each path name. There is one path name /dev/user for two files.

cpu% ls -q /dev|grep user
(0000000000000015 0 00) /dev/user
(000000000000000c 0 00) /dev/user

Globbing expands this to two elements:

cpu% echo /dev/user*
/dev/user /dev/user

I think this is not what the manual says. 

Then,

cpu% ls -q /dev/user*
(0000000000000015 0 00) /dev/user
(0000000000000015 0 00) /dev/user

I understand why it is so. But I think that consistency is sacrificed
for simplicity. Either rc should do what the manual says and return
one match for /dev/user* (so that /dev/user* and /dev/user is the same
thing), or ls -q /dev/user should recursively list all directory
entries matching the path name.

David Tolpin

Re: [9fans] ls, rc question

[David Tolpin]

I am not asking why there are two file names in the directory listing. I understand it.

I think that behaviours of rc and ls are confusing. I would either expect rc's globbing
to only match one path name, or ls to display all files.

man rc says 'A pattern is replaced by a list of arguments, one
for each path name matched'. Not for each directory entry. For
each path name. There is one path name /dev/user for two files.

cpu% ls -q /dev|grep user
(0000000000000015 0 00) /dev/user
(000000000000000c 0 00) /dev/user

Globbing expands this to two elements:

cpu% echo /dev/user*
/dev/user /dev/user

I think this is not what the manual says. 

Then,

cpu% ls -q /dev/user*
(0000000000000015 0 00) /dev/user
(0000000000000015 0 00) /dev/user

I understand why it is so. But I think that consistency is sacrificed
for simplicity. Either rc should do what the manual says and return
one match for /dev/user* (so that /dev/user* and /dev/user is the same
thing), or ls -q /dev/user should recursively list all directory
entries matching the path name.

David Tolpin