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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 25, 2009, 17:05 UTC
Message-ID: <7vws98y886.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.0904251155130.10279@pacific.mpi-cbg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 6 quoted lines

> It seems that accessing NTFS partitions with ufsd (at least on my EeePC)
> has an unnerving bug: if you link() a file and unlink() it right away,
> the target of the link() will have the correct size, but consist of NULs.
>
> It seems as if the calls are simply not serialized correctly, as single-stepping
> through the function move_temp_to_file() works flawlessly.

A few questions.

When this problem triggers for you,

 (1) do we have an open file descriptor to the tmpfile?

 (2) if so have we fsync'ed (or better yet, closed) it?

 (3) if the answers to the above are "yes, no", does it help the situation
     if we fsync the filedescriptor before calling move_temp_to_file()?

    ... gitster digs after asking questions to find answers himself ...

I realize that the answers seem to be "no, and the fd that created the tempfile has been closed". Hmm. Very curious.

So if you do:

	cat >corrupt-move.c <<\EOF
	#include <unistd.h>
	int main(int ac, char **av)
        {
                return (link(av[1], av[2]) || unlink(av[1]));
	}
	EOF
        cc -o corrupt-move corrupt-move.c
        ./corrupt-move corrupt-move.c corrupt-move.c.new

you end up with a corrupt-move.c.new file that is full of NUL?

Very curious...