From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5c952ea5ace5eb19dc04bc5363ba5952@vitanuova.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] union directories From: rog@vitanuova.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-djbojapqnnfxptvmykfdkdzkyw" Date: Mon, 3 Mar 2003 18:58:04 +0000 Topicbox-Message-UUID: 7721778a-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-djbojapqnnfxptvmykfdkdzkyw Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > 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. --upas-djbojapqnnfxptvmykfdkdzkyw Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-admin@cse.psu.edu> Received: from punt-2.mail.demon.net by mailstore for rog@vitanuova.com id 1046715077:20:29796:3657; Mon, 03 Mar 2003 18:11:17 GMT Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-2.mail.demon.net id ab2020192; 3 Mar 2003 18:07 GMT Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.6.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 939BE19A94; Mon, 3 Mar 2003 13:06:06 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from plan9.cs.bell-labs.com (ampl.com [204.178.31.2]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 102EF19A94 for <9fans@cse.psu.edu>; Mon, 3 Mar 2003 13:05:40 -0500 (EST) Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Mon Mar 3 13:05:38 EST 2003 Received: from 18.24.6.202 ([18.24.6.202]) by plan9; Mon Mar 3 13:05:36 EST 2003 Message-ID: <0a304f2dd88c5bdb8eb1ce403c53e037@plan9.bell-labs.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] union directories From: "Russ Cox" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Mon, 3 Mar 2003 13:05:41 -0500 > 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 --upas-djbojapqnnfxptvmykfdkdzkyw--