Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Message-ID:	<42297BA0.5DD70DD0@dessent.net>
Date:	Sat, 05 Mar 2005 01:28:00 -0800
From:	Brian Dessent <brian AT dessent DOT net>
Organization:	My own little world...
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: apparent bug: incorrect file position after write()
References:	<20050305090651 DOT B2AB31CE32B AT ws1-6 DOT us4 DOT outblaze DOT com>
X-IsSubscribed:	yes
Reply-To:	cygwin AT cygwin DOT com

"imaginate australiamail.com" wrote:
> 
> I'm experiencing unexpected behaviour under cygwin that as far as I
> know doesn't happen under linux.  I don't have access to linux to
> test at present.
> 
> Some successful write()s to a file increment the file's position by
> more than the count argument.  The extra byte(s) are added to the
> file's size and can be read by lseek()ing to the exact location
> where the extra byte(s) start.  When reading from a location prior
> to this location the extra byte(s) become invisible although they
> can affect the values returned from read() and lseek().

You have textmode mounts.  You write a single \n to the file as part of
your loop, "for (buf = 0; buf < LOOPMAX; buf++)".  Two bytes (\r\n) are
actually written.  That's the entire point of textmode mounts, to
silently translate \n into \r\n on write and the reverse on read.  If
you don't want that, then don't use textmode mounts.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -