Re: [9fans] ls, rc question -- proposed change to rc/glob.c

[rog@vitanuova.com]

i'm in a minority here, so i'll say this and then shut up.

i think the symlink comparison is not really valid, as a symbolic link
is a potentially useful entity in its own right (hence tools that can
look at them in both ways) whereas a duplicate name signifies nothing
beyond the fact that the directory might be a union directory; there's
nothing useful that can be done with the name.

what this discussion boils down to is epitomised by boyd's:

> large N% of the time it's not a problem, so Leave It Alone:

basically union directories are used hardly at all, and when they are,
it's generally only in "special purpose" places, such as /bin, /cron,
etc.  of course, they're crucial in the places where they are used,
but it's not really the general mechanism that one gets the impression
of when reading the documentation (as one quickly realises when trying
to do unusual things with it, such as bind onto directories in
/n/dump).

i have a feeling almost nothing would break if the kernel was changed
to disallow reading of union directories completely...

> the arguments seem to focus on whether with a change here or there
> they could be got to do a little more work (eg, by allowing * to
> iterate exactly once over all services, protocols, say).
> i don't think it's that essential in practice.

not essential.

it'd just be nice.

for what it's worth, i had a look through the programs that
geoff mentioned, categorising how they react to union directories.

no (or unlikely) adverse consequences:
	pptpd
		controls own namespace
	bitsy/keyboard
	faces
	ps
	winwatch
		displays duplicates (but union unlikely)
	aux/depend
	exportfs
		reflects duplicates in exported namespace
	cron
	du
	aux/listen
	mk
		do their own duplicate elimination
	history
		could produce erroneous results on snap (but union unlikely)

displays duplicate entries/info:
	acme
	news
		display duplicate entries
	netstat
		displays duplicate info

inefficient:
	mkfs
	gzip/zip
	scp
		produces duplicate copy of file
	vac
		stores duplicate directory entries

questionable:
	rm
		removes all entries, including hidden ones

erroneous:
	ip/ftpd
	ls
		displays duplicates, with non-stable reordering of entries.
	diff
		reports spurious extra entries
	tar
		doesn't work properly, (but probably for reasons
		unrelated to union directory reading (try {tar c /bin | tar t})

unknown:
	replica/revproto
		not sure.