From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Sat, 1 Nov 2008 10:04:53 -0500 From: "Eric Van Hensbergen" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4C2C9539-5ABB-4230-BC8A-A1765DFC0E1C@utopian.net> Subject: Re: [9fans] mv on directory Topicbox-Message-UUID: 2b24d1ac-ead4-11e9-9d60-3106f5b1d025 On Sat, Nov 1, 2008 at 9:17 AM, Rudolf Sykora wrote: >> There is dircp (in tar(1)) for moving trees around, or the long-form " @{cd >> fromdir && tar cp .} | @{cd todir && tar xT} ", if you prefer. > > I know that. It's a copy, not move. > >> But "behavior deviates from the similarly-named command in >> lunix" cannot be the definition of "bug." > > I just can't see any reason why to mention anything about any bug. I > didn't do that. > >> Again, "What should mv do to a tree that resides on multiple file servers?" > > what about: mv dirA dirB == > mkdir dirB > dircp dirA dirB > rm -r dirA > > ... if you are able to 'rm -r' (which also may span multiple > fileservers) than I don't see any trouble with moving the directories. > I would imagine that 99% of the time (more?) the behavior people desire would be what you describe. There are two parts to the problem: the application and the protocol. To have the protocol handle rename of anything other than single element (which may be the root of a tree) on a single file server is difficult -- however, it seems perfectly sensible to have the application fall back to the functionality you describe. Does anyone rely on the 'mv' command always having the atomic properties of a wstat? -eric