From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: [9fans] ls, rc question -- proposed change to rc/glob.c From: Charles Forsyth In-Reply-To: <000b01c40dc7$b8df6e40$1602a8c0@bl.belllabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Fri, 19 Mar 2004 16:02:54 +0000 Topicbox-Message-UUID: 3a0a3fec-eacd-11e9-9e20-41e7f4b1d025 >>I wouldn't mind if the kernel threw out the unreachable entries when >>you read a directory. However, I don't think its worth the effort or the trouble with that is that it's sometimes quite important to see that there are duplicates and what they are, if only to diagnose an unexpected effect caused by a union, so i think you'd need some way to give an equivalent effect, as i think rsc mentioned earlier. roger's away so i'll give his observation that the result of ls -l on a union directory (or reading a union directory and sorting it) will be less useful or even misleading unless the sort is stable. if you can rely on that, you know the attributes of the files of the same name below in the union appear in the correct order (which allows quick checks on the state of the union). of course, /proc/$pid/ns will give some of that for the directories involved, but when it is a particular file or files that you worry about, {ls -l | grep} seems a natural thing to use to check their attributes. as it happens, i don't think Plan 9's sort is stable: term% ls -l /bin|grep 8c --rwxrwxr-x M 9 forsyth inferno 303305 Dec 10 18:11 /bin/8c --rwxrwxr-x M 9 sys sys 299674 Feb 17 03:59 /bin/8c term% ls -l /bin/8c --rwxrwxr-x M 9 sys sys 299674 Feb 17 03:59 /bin/8c