Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Mon, 5 Feb 2001 17:21:42 +0100 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: lseek()/read() to physical drive returning wrong data. Message-ID: <20010205172142.C15821@cygbert.vinschen.de> Mail-Followup-To: cygwin AT cygwin DOT com References: <3A7C4445 DOT B5F8FAB0 AT compaq DOT com> <20010203191915 DOT Z19867 AT cygbert DOT vinschen DOT de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010203191915.Z19867@cygbert.vinschen.de>; from cygwin@cygwin.com on Sat, Feb 03, 2001 at 07:19:15PM +0100 On Sat, Feb 03, 2001 at 07:19:15PM +0100, Corinna Vinschen wrote: > 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. I have just checked in a patch to the Cygwin CVS repository which should allow bytewise lseek on raw disk devices at least for SEEK_SET and SEEK_CUR. For some reason my tests using SEEK_END (aka FILE_END) failed on my HD partition so using SEEK_END in the current implementation results in lseek returning -1 and errno set to EINVAL programatically. If anybody knows if that observation is correct or if I simply did something wrong I would gladly appreciate any hint. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin AT cygwin DOT com Red Hat, Inc. -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple