From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] correcting old failures, and NJ vs MA
From: forsyth@caldo.demon.co.uk
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20011011113633.7104419A4B@mail.cse.psu.edu>
Date: Thu, 11 Oct 2001 12:39:23 +0100
Topicbox-Message-UUID: 0658f614-eaca-11e9-9e20-41e7f4b1d025

>>Moving a directory can *NOT* be done in constant time without special
>>kernel support.  Even a Version 7 style unlink/link if it allowed
>>links to directories would at least allow it to be possible (though
>>with additional race conditions).

i see this rumbles on.  what i tried to point out in my video file example
(using a file not a directory but the point is the same)
is that unix doesn't do mv in constant time for either files or directories,
except in the particular case that both names point into the same physical file system.
otherwise it can only do what plan 9 does.

now, on all the out-of-the-box unix systems i looked at before
posting, of the set {/, /var, /tmp, /usr, /home} at least two were
always on different physical file systems, particularly /tmp and /usr
or /home.  i don't know why they do that when it's not necessary but
they do.  it would be worse if any possessed the chaos of automounted
NFS links i've seen on most large unix installations in the past.

i'd say all that makes it worse for the user because now i need to
understand the underlying file system topology to take advantage of the
optimisation and arguably it would be easier to understand under windows
which requires you to see all the device and partition boundaries!