Re: [9fans] union directories

[rog@vitanuova.com]

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

> Ls tells the truth!  I see no value in causing it to lie.

i'd like to be able to think of "ls" as showing me the files available
to me in a given directory.

files obscured within a union mount are not accessible to me; in fact,
apart from telling me that the directory probably contains a union
mount, information on those files is of no use at all.

there's a good implementation reason for having the duplicates show up
in raw reads (it only requires constant space in the kernel), but why
not get rid of the duplicates given that we're sorting the entries
anyway.

this isn't lying: it's showing a simplified version of the truth which
is not misleading (unlike the example in the lexnames paper).

> And then once ls lies, why doesn't ls *?  Why doesn't acme?

in fact, i think it's more important that * removes duplicates than ls.
i think it's a bug that:

	for (i in *) do something

can end up processing a single file multiple times.

acme the same - what's the point of showing me two of the same names
next to each other?  it just causes clutter. clicking on either
one performs exactly the same action.

> There might be good arguments that directory reads should
> reflect the information in the mount table, perhaps eliding
> duplicates and perhaps showing you the real stat info for 
> bound-over files (what you'd get with stat(2)).  Then again
> there are also good arguments for the way things are now.

mk was bitten by this at one stage.
it's a pity that
	ls -l | grep foo
doesn't necessarily give the same results as
	ls -ld foo

now that's a genuine case of ls (or at least unionread()) lying...
i agree about the arguments for the current behaviour though.

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

From: "Russ Cox" <rsc@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] union directories
Date: Mon, 3 Mar 2003 13:05:41 -0500
Message-ID: <0a304f2dd88c5bdb8eb1ce403c53e037@plan9.bell-labs.com>

> Actually I have had more Unix-oriented folks ask me if in a union ls 
> there could be an option, per-file, to display the binding for that file 
> when there is more than one. 

Per-file options are a bad idea not even worth talking about.

> I got real complaints from people about seeing multiple files with the 
> same name on an ls. 

Ls tells the truth!  I see no value in causing it to lie.
And then once ls lies, why doesn't ls *?  Why doesn't acme?
Ls does one thing.  It does it well.  It's consistent with the
rest of the system.  If you want sort -u, you know where to
find it.

There might be good arguments that directory reads should
reflect the information in the mount table, perhaps eliding
duplicates and perhaps showing you the real stat info for 
bound-over files (what you'd get with stat(2)).  Then again
there are also good arguments for the way things are now.

Read the ksh example in the lexnames paper.  The last thing we
need is user-space programs that ``patch'' kernel behaviors.
Arguing that the kernel needs fixing might be reasonable.
Changing ls to hack around perceived kernel deficiencies
is the path to madness (or to Linux, take your pick).

Russ