Re: [PATCH v3] Add an option not to use link(src, dest) && unlink(src) when that is unreliable

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Apr 27, 2009, 20:13 UTC
Message-ID: <alpine.LFD.2.00.0904271304300.22156@localhost.localdomain>
In-Reply-To: <7vljpl3m8i.fsf@gitster.siamese.dyndns.org>

On Mon, 27 Apr 2009, Junio C Hamano wrote:

> 
> The coda hack comment in move_temp_to_file() shows what we can do to
> autodetect (i.e. try cross directory hardlink)

The thing is, we cannot do it reliably across different systems.

Coda simply doesn't _support_ hardlinks across directories at all. So it will always return an error when you try, and you can see the error directly and easily.

> but I somehow thought that we changed the code enough to ensure that we 
> create the tmpfiles in the same directory as their final destination?

This was for a totally different case - a certain kind of NFS client bug with a certain kind of (arguably buggy, but I can understand it because NFS is just a bad protocol in this respect) NFS server, where you may be able to do cross-directory renames, but it caused problems later.

Now, the reason cross-directory name movement matters is that it makes many things much harder, and filesystems thus have a much harder time doing them well (or decide to not support them at all, as in Coda). Within a single directory, things are just simpler, and thus less likely to hit bugs.

IOW, with cross-directory link/rename, you didn't get an error, you got some unreliable behavior - very much like the thing we see with ufsd. But with those problems, we could fix it by just always making the link and the rename be within a single directory.

Now, it seems, even being in the same directory isn't sufficient for that ufsd thing (but rename works. Knock wood).

			Linus