Re: trouble on windows network share

David Goldfarb [off-list ref] writes:

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.

    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