Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/