Re: index-pack died on pread

From: Alex Riesen <raa.lkml@gmail.com>
Date: Jul 26, 2007, 16:51 UTC
Message-ID: <81b0412b0707260951h57fc91dbsd5a0a126f0e16fee@mail.gmail.com>
In-Reply-To: <alpine.LFD.0.999.0707260911040.3442@woody.linux-foundation.org>

On 7/26/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

Show 10 quoted lines

> On Thu, 26 Jul 2007, Alex Riesen wrote:
> > >
> > > It's true that pread() is used much less than normal reads, and maybe the
> > > cygwin pread() is indeed broken. But it's intriguing how apparently both
> > > HP-UX and Cygwin are showing the same breakage.
> >
> > Maybe because neither _has_ POSIX pread?
>
> HP-UX? No pread()? It wouldn't link if it didn't have pread(). So it
> clearly has pread(), it's just somehow broken.

I remember it didn't and was emulated with lseek.

Show 8 quoted lines

> > This is cygwin's pread, I believe:
> >
> > http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc?rev=1.225&content-type=text/x-cvsweb-markup&cvsroot=src
>
> I'm not saying that's great programming, but the "git_pread()" that git
> will use in the absense of a real pread() is actually even *less* of a
> POSIX pread, since it doesn't even try to save/restore the old position
> (it knows that git doesn't care).

Not that. I meant the value read returned wasn't checked nor returned. Suppose read failed (on Windows it happens all the time, especially if you stress it a bit) - you'll never know it did and the buffer will contain either garbage or previous data. Now imagine we _did_ have a past-eof condition or bleeding into sign-bit (because of some 64-bit confusion)...

> So I don't think that explains why git doesn't like cygwin's pread. I
> suspect an earlier version of cygwin had an even more broken version of
> pread at some point.

Yep, that could be another reason.