From: jqb AT netcom DOT com (Jim Balter)
Subject: Re: Patch for reliable rcs on win95
20 Mar 1997 20:40:41 -0800
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <3332019E.1826.cygnus.gnu-win32@netcom.com>
References: <199703181622 DOT JAA04349 AT nz1 DOT netzone DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01Gold (WinNT; I)
Original-To: Mikey <jeffdb AT netzone DOT com>
Original-CC: cygnus <gnu-win32 AT cygnus DOT com>
Original-Sender: owner-gnu-win32 AT cygnus DOT com

Mikey wrote:
> 
> Jim I think it's fast_copy in rcsutil, that exibits this behavior in rcs,
> ignoring the size of the returned read. under linux you either get what you
> asked for, EOF or an error, and some programs count on this behavior
> including rcs.
> 
> To see an example do ci -u filename
> rcs -U filename
> make some changes to the file
> export strace=1,strace.log
> and use rcs configured as default (without large_memory) to do
> ci -u filename
> when you read through the strace.log file, you should see something like
> 
> read (3, 0x4683004, 1024)
> 1024=read(3, 0x4683004, 1024)
> write (4, 0x4683004, 1024)
> 1024 = write(4, 0x4683004, 1024)
> read (3, 0x4683004, 1024)
> 921 = read(3, 0x4683004, 1024)  << short read
> write (4, 0x4683004, 1024)  << ignored

If anyone has been following this or cares, Mikey (MikeY? jeffdb?)
sent me some actual trace output that indicates that there is a
misdiagnosis going on here.  The "short read" above was short
because it hit EOF.  The write wrote 1024 because it had that much
in the stdio buffer.  Note that, while in the above made up trace
the buffer addresses are the same, they are not in the real trace.
The read and write not related, at least not in any simple fashion.

So, this is not evidence that short reads are happening or that they
are causing a problem.  In fact, since a file copy or filter would
always have to check the read count to know when EOF was encountered,
there are very few instances in which it could be assumed that read
filled the buffer and have it work on any system; these would be cases
like reading a file header or magic number, and those should most
definitely be done in binary mode anyway.

Which is not to say there is no problem; MikeY's file definitely
got truncated, and that's a serious problem worth tracking down,
but so far I haven't seen any evidence that Window 95 reads less
data than it was asked for, in case anyone was worried.
Nor is there any evidence that the fact that cygwin.dll does short
reads on text files is causing a problem.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".