This is the mail archive of the
mailing list for the Cygwin project.
On Wed, Sep 13, 2006 at 04:38:33AM +0000, Eric Blake wrote:
>> At any rate, thanks for narrowing down your application
>> to a smaller test case; I'll see what I can find with it.
>Here's something interesting in the strace:
> 30 518741 [main] bash 2084 readv: readv (255, 0x22C060, 1) blocking, sigcatchers 1
> 30 518771 [main] bash 2084 readv: no need to call ready_for_read
> 34 518805 [main] bash 2084 fhandler_base::read: read 0 bytes ()
> 29 518834 [main] bash 2084 fhandler_base::read: returning 135, text mode
> 33 1682871 [main] bash 2084 fhandler_base::lseek: lseek (/home/eblake/text/zzz.sh, -103, 1)
> 32 1682903 [main] bash 2084 fhandler_base::lseek: setting file pointer to 429
>4967295 (high), 4294967193 (low)
> 34 1682937 [main] bash 2084 lseek64: 39 = lseek (255, -103, 1)
>Seems like a text mode lseek bug (no surprise there, since cgf
>predicted that there are still some corner cases). The file is 142
>bytes, but has seven \r\n pairs, so the readv correctly returned 135
>characters read. But the lseek back to the start of the third line
>temporarily set the file pointer to -3,
(actually -103, 4294967193U == -103)
>then settled on an offset of 39 (39 + 103 gives 142 bytes, as if in
>binary mode); the offset really should have been 32 characters in (byte
>34 is the start of the third line, so two \r would be skipped at that
>point). I'm still not sure if it is bash's fault or cygwin's. But the
>file definitely was read in text mode when it resided in a text mount.
Is bash assuming that it can read N characters and then subtract M
characters from the current position to get back to the beginning of a
line? If so, hmm. I guess this explains why it was reading a byte at a
time before. It must be counting characters rather than calling lseek
to figure out where it is.
Fixing this is rarely as simple as just calling lseek, though, of
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html