RE: trouble on windows network share
Show 33 quoted lines
> -----Original Message-----
> From: David Goldfarb
> Sent: Wednesday, May 08, 2013 5:38 AM
>
> Here's one more data point. It suggests that the problem is due to
> either Cygwin or possibly Git 1.7.9.
>
>
> My Ubuntu box is actually a VM, hosted by my windows box in VMWare
> Player.
>
> So, I tried using the VMWare shared folder feature, to mount the
> Windows U: drive (which is physically on the WD NAS box) as
> /mnt/hgfs/Host-U on Ubuntu.
> Then, I tried linux on the Ubuntu box, fully expecting it to fail as it
> trampolined through Windows connection to the NAS box).
>
> But, it worked fine.
>
> So, at this point, it became likely that the problem is tied to the
> different version of Git that I have on the two machines:
> - On Ubuntu, git version 1.7.10.4
> - On Windows, Cygwin's git version 1.7.9 (which appears to be the
> latest version for Cygwin).
>
> So, I installed Git on Windows from http://git-scm.com/download/win.
> Git version 1.8.1.msysgit.1
>
> Triumph: Git on windows works with this git but, on the same file and
> repo, fails with Cygwin git.
>
> So, either something relevant changed in Git 1.7.10, or (more likely)
> this is a Cygwin issue.
>
>
> Jason, are you also using Cygwin git? Are you also using a WD NAS?
Cygwin, yes. I am going to spend some time (likely this weekend) to get the current version to compile on Cygwin.
WD NAS, no. Windows Server 2008 with NTFS file system on internal raid.
Show 83 quoted lines
>
> David
>
> -----Original Message-----
> From: Pyeron, Jason J CTR (US) [mailto:jason.j.pyeron.ctr@mail.mil]
> Sent: Monday, May 06, 2013 4:11 PM
> To: Thomas Rast; David Goldfarb
> Cc: git@vger.kernel.org
> Subject: 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 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
>