David Goldfarb <d...@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

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to