Re: trouble on windows network share

From: Thomas Rast <trast@inf.ethz.ch>
Date: May 6, 2013, 10:08 UTC
Message-ID: <878v3sh14d.fsf@linux-k42r.v.cablecom.net>
In-Reply-To: <8B6563E531152E4190313499F193F94214AAAB42@mbx500-u1-lo-3.exch500.msoutlookonline.net>

David Goldfarb <deg@degel.com> writes:

Show 29 quoted lines

> Looks like it works.
>
> From the windows machine:
>     U:\foo>git cat-file -p 0b89efdeef245ed6a0a7eacc5c578629a141f856
>     100644 blob b02e7c87fe376a353ea4f014bdb3f5200a946b37    foo1
>     100644 blob 2cbf64f759a62392ad9dfe1fb9c2cdb175876014    foo2
>
>     U:\foo>
>
>
> Double-checking that nothing was fixed or changed when I earlier committed the file from Linux, here's a second test:
>
>
>     U:\foo>git cat-file -p 0b89efdeef245ed6a0a7eacc5c578629a141f856
>     100644 blob b02e7c87fe376a353ea4f014bdb3f5200a946b37    foo1
>     100644 blob 2cbf64f759a62392ad9dfe1fb9c2cdb175876014    foo2
>     
>     U:\foo>git status
>     # On branch master
>     # Untracked files:
>     #   (use "git add <file>..." to include in what will be committed)
>     #
>     #       trace1
>     #       trace2
>     nothing added to commit but untracked files present (use "git add" to track)
>     
>     U:\foo>git add trace1
>     
>     U:\foo>git commit trace1 -m "testing"

Note that specifying 'trace1' here is redundant, since you already added it and had no other staged changes. Perhaps you can re-run a test like this without the extra argument for comparison. That would tell us if it matters that the write and read happen in the same process.

Show 8 quoted lines

>     error: unable to find cecae5b4c87ea21aef513fcfcd5c27fe87e0536f
>     fatal: cecae5b4c87ea21aef513fcfcd5c27fe87e0536f is not a valid object
>     
>     U:\foo>git cat-file -p cecae5b4c87ea21aef513fcfcd5c27fe87e0536f
>     100644 blob b02e7c87fe376a353ea4f014bdb3f5200a946b37    foo1
>     100644 blob 2cbf64f759a62392ad9dfe1fb9c2cdb175876014    foo2
>     100644 blob 19102815663d23f8b75a47e7a01965dcdc96468c    test.txt
>     100644 blob c9009b02950964cf1d5281125e6e2f647dd9dc16    trace1

I'm inclined to just say that your FS is crazy.

What's unsatisfactory is that we already have a bunch of crazy FS workarounds in move_temp_to_file(), which is one obvious candidate for what is going on here. So this wouldn't be something new; just another craziness to work around.

For example, you could test the theory that rename() has something to do with it by patching this into move_temp_to_file():

diff --git i/sha1_file.c w/sha1_file.c
index 67e815b..22af015 100644
--- i/sha1_file.c
+++ w/sha1_file.c
@@ -2635,6 +2635,10 @@ int move_temp_to_file(const char *tmpfile, const char *filename)
 		/* FIXME!!! Collision check here ? */
 	}
 
+	if (access(filename, R_OK) < 0)
+		return error("access(%s, R_OK) failed immediately after rename(): %s",
+			     filename, strerror(errno));
+
 out:
 	if (adjust_shared_perm(filename))
 		return error("unable to set permission to '%s'", filename);

-- 
Thomas Rast
trast@{inf,student}.ethz.ch