Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 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...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html