Re: Serious I/O bugs in B20 release

[Paul McFerrin <paulmcferrin@worldnet.att.net>]

Thank you for your reply.  I have subscribed to the mailing list.
FYI - cat and my cpio DOES it's open with O_BINARY so the reads are in
binary mode.  Thus control-Z should not be my problem.

-paul mcferrin


Chris Faylor wrote:
> 
> As you're probably aware, cygwin is essentially a free software project.
> Like most free software projects, it has a mailing list where you can
> report problems like this and get help from the community of people
> using the product.
> 
> The mailing list is cygwin@sourceware.cygnus.com.  You can subscribe
> to it by sending email to cygwin-subscribe@sourceware.cygnus.com.
> 
> Your problems are probably due to the fact that your file contains
> a CTRL-Z character, which is interpreted as an EOF.  You should investigate
> the mount command which has a '-b' option which will force all reads
> and writes to be in 'binary' mode.
> 
> You should also check out the various other resources available at
> our web page:  http://sourceware.cygnus.com/cygwin/
> 
> I've redirected followups to the mailing list.  I would appreciate it
> if you would send any further comments or bug reports there.
> 
> -chris
> 
> On Mon, Aug 16, 1999 at 02:07:13AM -0400, Paul McFerrin wrote:
> >Folks:
> >
> >What is the mechanism for reporting bugs in CYGWIN?  I have a read(2)
> >bug to report when reading files with "holes" in allocated blocks.  For
> >examplem I can do the following:
> >
> >       $ cat file_A >file_B
> >
> >where file_A contains over 1MB of data amd file_B will end up having
> >less than 800 bytes!  This is with the distributed "cat".
> >
> >I've ported Free-BSD cpio command and I can't read the cpio archive
> >created without getting a premature EOF because of the holes in the
> >file.  The cpio and "cat" command are doing simple read(fd, buff, len)
> >and are returning a "0" when it encounters a hole.
> >
> >The "cp" command copies these files just fine because of the code
> >present to handle holes.
> >
> >I'm including a sample file (zz.gz) that will demostrate the problem.
> >Just do:
> >
> >       $ gunzip zz
> >       $ cat zz >yy
> >       $ ls -l zz yy
> >
> >I've also discovered that when using "cat" the output file will be
> >BIGGER!  Just do:
> >
> >       $ cd /tmp
> >       $ cat /etc/termcap >term
> >       $ ls -l /etc/termcap term
> >       $ cmp -l /etc/termcap term
> >
> >The files will not be identical.
> >
> >BTW:  I've seen this type of read problems with Delorie's djgpp
> >package.  Did he write some of this code??? :+)
> >
> >If you are not the correct one to report "bugs" to, please ley me know.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com