From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 1 Nov 2008 14:25:44 -0700 From: Roman Shaposhnik In-reply-to: <785E9BE8-7F20-418B-9DA3-4BC46A3A98B0@utopian.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: MIME-version: 1.0 Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <785E9BE8-7F20-418B-9DA3-4BC46A3A98B0@utopian.net> Subject: Re: [9fans] mv on directory Topicbox-Message-UUID: 2c27c140-ead4-11e9-9d60-3106f5b1d025 On Nov 1, 2008, at 9:30 AM, Josh Wood wrote: > All that said, it's not like I've never cursed a directory that > wouldn't mv for me in Plan 9 -- so if someone had an answer for > Rob's question: "What should mv do to a tree that resides on > multiple file servers?", it could be interesting to discuss. I don't > think arguing from rm -r is a good tact, though, because of the > differing risk levels between a failed delete and a failed move. One > might afford convenience in the former, and eschew it in the latter. That's a very good point. UNIX in general does guarantee certain things about rename of the subdirectories within the same FS, but the price they pay in the kernel and elsewhere (NFS being the prime example) seems just too high (the original explanation given by a friend of mine who wrote this was much more colorful, but I guess guys like IBM & co. cleaned up kernel comments quite a bit ;-)): http://lxr.linux.no/linux+v2.6.27.4/fs/namei.c#L2479 The behavior of mv(1) as defined by POSIX seems to build on top of the rename-within-the-same-FS guarantee, which, in case of Plan9 is not applicable. Thus it would be an interesting thought exercise to go over the POSIX text: http://www.opengroup.org/onlinepubs/009695399/ and see how much of the required subdirectory move semantics could be preserved even though we lack one of the basic building blocks that makes it behave like it does on UNIX. Thanks, Roman.