Re: trouble on windows network share

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Goldfarb <deg@xxxxxxxxx> 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
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]