RE: trouble on windows network share

> -----Original Message-----
> From: Thomas Rast
> Sent: Monday, May 06, 2013 5:42 AM
> 
> David Goldfarb <deg@degel.com> 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 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