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: <20011008062832.V28720@cackle.proxima.alt.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 8 Oct 2001 00:49:30 -0400 Topicbox-Message-UUID: 00032e42-eaca-11e9-9e20-41e7f4b1d025 On Mon, 8 Oct 2001, Lucio De Re wrote: > On Sun, Oct 07, 2001 at 12:23:59PM -0400, jmk@plan9.bell-labs.com wrote: > > > > As Dave points out, there are a lot of balls in the air during > > an atomic 'rename'. 4.2BSD introduced the 'rename' system call, > > and as an alpha/beta tester for 4.1[abc] and 4.2BSD I can testify > > to how long it took to get it right and how much ugly code was > > involved. So can anybody who had seen current 4.4BSD derivatives. _None_ of them got it right. rename()/rename() race (creating a loop and detaching it from the rest of tree) is still there. > There are really only two social factors overriding here. People > like me have grown to expect it, unfortunate as it may be, and the > alternative is inconsistent and open to error, besides being much > more time and resource intensive. > I should imagine that BSD "rename" must have been made orders of > magnitude more complex by symbolic links. After all, SysV 3.2 "mv" > could rename directories into other directories in the same > filesystem, couldn't it? It's been a long time since my 3B2 was Same race + metric buttload of other fun stuff. And then there is _really_ fun stuff in userland. Like find / mv and rm -rf / mv races that allow any user to create a deep tree in /tmp, wait for cron-ran script to start removing it and do something along the lines of mv /tmp/foo/bar/baz /tmp/quux, tricking find(1) or rm(1) into walking up into the root and proceeding from there. Works like charm on almost all Unices I've seen. Sure, it's a broken userland and it needs to be fixed whenever such bugs are found, but the point is that writing correct tree-walker that would deal gracefully with cross-directory renames is _nasty_.