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.chOk. Continuing in the same shell:
U:\foo>git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: trace1
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# trace2
U:\foo>git commit -m "test b"
error: Trying to write ref refs/heads/master with nonexistent object 428dafc292b8396fc7b3c7f692dc9dfe1196a40a
fatal: cannot update HEAD ref
U:\foo>dir /s *a40a
Volume in drive U is Users
Volume Serial Number is FC97-3DA5
Directory of U:\foo\.git\objects\42
05/06/2013 12:26 PM 152 8dafc292b8396fc7b3c7f692dc9dfe1196a40a
1 File(s) 152 bytes
Total Files Listed:
1 File(s) 152 bytes
0 Dir(s) 1,594,477,576,192 bytes free
U:\foo>date
The current date is: Mon 05/06/2013
Enter the new date: (mm-dd-yy)
U:\foo>time
The current time is: 13:10:49.55
Enter the new time:
U:\foo>git cat-file -p 428dafc292b8396fc7b3c7f692dc9dfe1196a40a
tree cecae5b4c87ea21aef513fcfcd5c27fe87e0536f
parent f6a0de35d12a3b58f12bf1af4ff629b8b004ad82
author David Goldfarb [off-list ref] 1367834997 +0300
committer David Goldfarb [off-list ref] 1367834997 +0300
test b
U:\foo>U:\foo>
David
-----Original Message-----
From: Thomas Rast [mailto:trast@inf.ethz.ch]
Sent: Monday, May 06, 2013 1:08 PM
To: David Goldfarb
Cc: git@vger.kernel.org
Subject: 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
Oops, I earlier missed the second half of your message, where you suggested that I patch move_temp_to_file().
Sorry, I don't have the tool-chain or knowledge to recompile git into this win/Cygwin environment.
What I can do, realistically, is:
- Follow exact instructions.
- (with some obvious hesitation) run executables that you send me.
- Continue whatever tests you want with my existing git.
Note, too, that:
- This is occurring on a standard, off-the-shelf, NAS box, the Western Digital "My Book Live"
- I would guess that the "craziness" has more to do with the box's network stack than with its FS, since it behaves fine when mounted on Linux, but not on Windows.
David
-----Original Message-----
From: David Goldfarb
Sent: Monday, May 06, 2013 1:13 PM
To: 'Thomas Rast'
Cc: git@vger.kernel.org
Subject: RE: trouble on windows network share
Ok. Continuing in the same shell:
U:\foo>git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: trace1
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# trace2
U:\foo>git commit -m "test b"
error: Trying to write ref refs/heads/master with nonexistent object 428dafc292b8396fc7b3c7f692dc9dfe1196a40a
fatal: cannot update HEAD ref
U:\foo>dir /s *a40a
Volume in drive U is Users
Volume Serial Number is FC97-3DA5
Directory of U:\foo\.git\objects\42
05/06/2013 12:26 PM 152 8dafc292b8396fc7b3c7f692dc9dfe1196a40a
1 File(s) 152 bytes
Total Files Listed:
1 File(s) 152 bytes
0 Dir(s) 1,594,477,576,192 bytes free
U:\foo>date
The current date is: Mon 05/06/2013
Enter the new date: (mm-dd-yy)
U:\foo>time
The current time is: 13:10:49.55
Enter the new time:
U:\foo>git cat-file -p 428dafc292b8396fc7b3c7f692dc9dfe1196a40a
tree cecae5b4c87ea21aef513fcfcd5c27fe87e0536f
parent f6a0de35d12a3b58f12bf1af4ff629b8b004ad82
author David Goldfarb [off-list ref] 1367834997 +0300
committer David Goldfarb [off-list ref] 1367834997 +0300
test b
U:\foo>U:\foo>
David
-----Original Message-----
From: Thomas Rast [mailto:trast@inf.ethz.ch]
Sent: Monday, May 06, 2013 1:08 PM
To: David Goldfarb
Cc: git@vger.kernel.org
Subject: 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