Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sources.redhat.com Delivered-To: mailing list cygwin@sources.redhat.com Date: Sat, 3 Feb 2001 19:19:15 +0100 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: lseek()/read() to physical drive returning wrong data. Message-ID: <20010203191915.Z19867@cygbert.vinschen.de> Mail-Followup-To: cygwin@cygwin.com References: <3A7C4445.B5F8FAB0@compaq.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A7C4445.B5F8FAB0@compaq.com>; from Robin.Miller@compaq.com on Sat, Feb 03, 2001 at 12:47:49PM -0500 On Sat, Feb 03, 2001 at 12:47:49PM -0500, Robin T. Miller wrote: > Hi All, > I have a Unix test program named 'dt' which runs with Cygwin. > This program tests a variety of devices as well as file systems. The > tests which use lseek() to raw mounted disks, are failing with data > compare errors. It appears either lseek() is positioning incorrectly > or read() is returning the wrong data after lseek'ing. > > This random I/O sequence seems to work correctly to a regular > file, so maybe the raw device buffering is messing up? I'm not sure. Lseek on raw devices isn't yet fully implemented. The underlying *cough* operating system *cough* isn't able to do a bytewise access to the raw device but only in steps of 512 bytes. A full lseek implementation would need to do it's own buffering to simulate bytewise buffering. This is still missing. > The only other program restrictions is 32-bit file offsets. > > BTW: Are there any plans to release 64-bit file support? Not in the near future. Nobody would complain about contributions, though... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin@cygwin.com Red Hat, Inc. -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple