> -----Original Message----- > From: Thomas Rast > Sent: Monday, May 06, 2013 5:42 AM > > David Goldfarb <deg@xxxxxxxxx> writes: > > > Git works correctly under Linux (Ubuntu 12.04; git 1.7.9.5). I've > attached the strace outputs. (Note: for reasons that are probably > irrelevant, I needed to run the commands sudo'd. Shout back if this is > an issue). > > > > Under Windows 7, Cygwin git 1.7.9, commit fails: > > U:\foo>git commit -m "added foo2" > > error: unable to find 0b89efdeef245ed6a0a7eacc5c578629a141f856 > > fatal: 0b89efdeef245ed6a0a7eacc5c578629a141f856 is not a valid > object > > > > For what it's worth, note that the file does exist. > > U:\foo>ls -l .git/objects/0b > > total 1024 > > -rwxrw-r-- 1 ???????? ???????? 74 May 5 01:15 > 89efdeef245ed6a0a7eacc5c578629a141f856 > > > > (I'm not sure why the permissions are trashed. Seems to be a Cygwin > thing, or maybe my Cygwin config. The "??????" also appears on local > files, and I believe also with files on the old Buffalo drive, so I > don't think it is relevant to the problem). Just in case, here's the > same dir, as seen from the Ubuntu VM: > > > > deg@ubuntu:/mnt/users/foo$ ls -l .git/objects/0b > > total 64 > > -rwxr-xr-x 0 root root 74 May 5 01:15 > 89efdeef245ed6a0a7eacc5c578629a141f856 > > > > Again, note that there is some user permissions lossage here. I don't > know enough about Linux mount or CIFS, and apparently did the mount in > a way that everything seems to appear to be stuck owned by root. (same > problem I hinted at above). Hope this is not relevant to the problem. > > > > Here's how the same directory looks, when I'm ssh'd into the NAS box > itself: > > > > CentralPark:/shares/Users/foo# ls -l .git/objects/0b > > total 64 > > -rwxrw-r-- 1 deg share 74 May 5 01:15 > 89efdeef245ed6a0a7eacc5c578629a141f856 > > > > In any event, the symptoms don't seem to be a permissions problem, so > all this extra info is probably just a red herring, I hope. > > Hrm. What about what Jeff already asked of the OP (and AFAICS never > got > a reply)? If referring to me, then yes but it was too big for the list. > > } If it's a race condition between the write and the subsequent read in > } the same process, then it would be solved by looking at the object > } later. Does "git cat-file -p > 6838761d549cf76033d2e9faf5954e62839eb25d" > } work, or is the object forever inaccessible? > > In your case: git cat-file -p 0b89efdeef245ed6a0a7eacc5c578629a141f856
<<attachment: smime.p7s>>