From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Viro To: 9fans@cse.psu.edu Subject: Re: [9fans] mv vs cp In-Reply-To: <87eloeax62.fsf@becket.becket.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 9 Oct 2001 05:33:50 -0400 Topicbox-Message-UUID: 02e290d0-eaca-11e9-9e20-41e7f4b1d025 On Tue, 9 Oct 2001, Thomas Bushnell, BSG wrote: > It's adequate to do this on a per-filesystem basis (assuming you > prohibit cross-device renames), so the Hurd can conveniently do it in BTDT (see fs/namei.c::vfs_rename_dir() in Linux 2.4.x). But that's far from the only annoying piece of shit in rename(2) semantics. E.g. you are getting very ugly locking rules if you want to handle the case of rename() removing an empty directory correctly. Again, I've really been there and done that. It wasn't pretty and I would be much happier if rename() couldn't change the topology. We couldn't do that since it would break a lot of userland stuff; Plan 9 has a luxury of dropping annoying crap and being able to find and fix resulting breakage in userland. In this case crap is not there in the first place, so introducing it would cause a lot of ugliness in the kernel for no good reason. > individual servers (and does); Plan 9 could do the same I would > suspect. I suspect that Hurd has slightly, erm, different design philosophy (and that's about the only printable comment I can make on the thing, so let's not go there).