delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2005/09/23/05:28:56

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
Date: Fri, 23 Sep 2005 11:28:16 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Anyone know about interaction of 'dd' with memory cards?
Message-ID: <20050923092816.GA4833@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <SERRANO1IfpT8vWyu9k000001df AT SERRANO DOT CAM DOT ARTIMI DOT COM> <4333525E DOT 5070003 AT byu DOT net>
Mime-Version: 1.0
In-Reply-To: <4333525E.5070003@byu.net>
User-Agent: Mutt/1.4.2i

On Sep 22 18:54, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to Dave Korn on 9/22/2005 11:22 AM:
> >   Now, dd is supposed to terminate the copy operation when it reaches EOF on
> > the input, and I doubt that is broken.  What I'm wondering is, I _expected_
> > that reading /dev/sdb would give an EOF when the entire drive's contents had
> > been read.  Was this a false assumption?  Is Cygwin _supposed_ to return an
> > EOF when you reach the end of a device volume, and it (or dd) is broken, or
> > has this never been implemented?
> 
> Have you tried it on Linux, for comparison?  If anything, it is cygwin and
> not dd that is at fault here (your analysis about dd stopping at EOF is
> correct), although I don't know if Windows provides enough hooks for
> cygwin to detect end of disk to turn that into EOF.

Dunno if that helps, but AFAICS, there's Windows at fault, not Cygwin.
I tried running dd as Dave did, reading from Compact Flash and Memory Stick.

I got a very different result, but it's still weird.  For instance, reading
from an 8 Megs Memory Stick:

  $ strace -o dd.out dd if=/dev/hdc of=ms.img bs=1024

  [Time passes, somewhat more than a minute...]

  dd: reading `/dev/sdc': Permission denied
  7920+0 records in
  7920+0 records out
  8110080 bytes (8.1 MB) copied, 63.66 seconds, 127 kB/s

Ok, let's have a look into the strace output.  This is the interesting
point (slightly rearranged for better readability):

    20 10560402 [main] dd 1428 fhandler_dev_raw::raw_read: read 61440 bytes
                         from file into buffer
52702874 63263276 [main] dd 1428 fhandler_dev_raw::read_file: 0 (err 121) =
                         ReadFile (1584, 268508024, to_read 61440, read 0, 0)
   95 63263371 [main] dd 1428 seterrno_from_win_error:
                         /src/cygwin/winsup/cygwin/fhandler_raw.cc:206
                         windows error 121
   27 63263398 [main] dd 1428 geterrno_from_win_error: unknown windows
                         error 121, setting errno to 13
 
So what we have here is the last call to ReadFile on the raw device.
The previous call has read exactly the last 61440 bytes from the medium.
The above call is the one which is supposed to return 0 bytes, EOF.

But it doesn't.  Instead, it *times out* after about 52 seconds (Huh?)
with Windows error 121.  So, what's that, Windows error 121:

  $ net helpmsg 121

  The semaphore timeout period has expired.

Er... am I in the wrong movie or what?  What semaphore, please?

Dave, you will have to debug this on your machine.  What does ReadFile
in fhandler_dev_raw::read_file() do on your machine?  When it reads
beyond the physical EOF, how many bytes does ReadFile return?  What
does it actually copy to the buffer?

And then the interesting question occurs... why is it different on
your machine than it is on mine?  Do differences between card readers
influence what happens?  Is that another driver?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat, Inc.

--
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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019