Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: ericblake AT comcast DOT net (Eric Blake)
To: Matthias Bertschy <matthias AT echotech DOT ch>, cygwin AT cygwin DOT com
Subject: Re: impossible to restore MBR using dd
Date: Tue, 03 May 2005 18:06:12 +0000
Message-Id: <050320051806.4132.4277BD93000F03C60000102422069984990A050E040D0C079D0A@comcast.net>

> Hello Blake,

I prefer my given name over my surname, but answer to both (the curse
of the dual first name)...

> >
> >Hmm - writing just 446 bytes to raw devices is not very safe.  /dev/sda is a 
> block-special device for a reason, and writing anything more or less than a full 
> block at a time on a block-special device is not guaranteed to work.  Maybe that 
> is your problem?  Also, according to `stat /dev/sda', the IO block size of an 
> NTFS raw device is 1024, so even bs=512 may be equally dangerous.
> >
> >  
> >
> Maybe I should recall you that on Linux, we can safely write 446 bytes 
> blocks to a raw device. Indeed, the command dd if=boot.MBR of=/dev/sda 
> bs=446 count=1 works under Linux.
> I also don't understand why you are using NTSF raw devices to access the 
> MBR... after all the MBR isn't formatted at all !

The limitation here is not in dd, but in cygwin-1.5.16's use of the underlying
Window's features to access raw devices.  Just because Linux has chosen
to allow a non-block access of a block-special device (implemented as a block
read, edit, block write sequence), it does not mean that Windows has to do
likewise.  Perhaps cygwin 1.5.17 can be patched to do a read-write sequence
on block-special raw devices when write(2) is unaligned or not a full block, at
which point dd would automatically work in the way you desire.  And if you
really want that feature, consider patching cygwin yourself.  Also, from your
original description, it sounds like write(2) was failing with ENOSPC when
Windows rejected the non-aligned write, although the better error to comply
with POSIX would have been ENXIO for a request outside of the device's
capabilities.  I'd have to see an strace output to be sure (but right now I'm
not brave enough to risk overwriting my own MBR as an experiment to generate
such an strace output).

In the meantime, do as was suggested elsewhere in this thread - read the
entire MBR block into a regular file, write your 466 bytes to the first portion of the
regular file, then write the entire block back to the raw device.  Then all
accesses to block-special devices are on block boundaries, and will be portable.

> 
> I think I will fill a bug report for the dd command under Cygwin. Could 
> you point me where to do it?
> (or maybe for Cygwin's ability to access raw devices)

This mailing list is the right place - your feature request is duly noted.  However,
I make no promises as to whether it is fixable (it may be as designed, and
therefore not a bug); as I said earlier, accessing block-special devices on
non-block boundaries is inherently non-portable.

> >That's to be expected.  The of= flag is necessary to tell dd to put the output 
> in the named (device) file, rather than on stdout.
> >  
> >
> I know :-) that was just to point out that without any bs parameter, the 
> dd command works.

And that's because dd without the bs= parameter defaults to bs=512, and dd
without the of= parameter defaults to stdout, which is not a block-special
device, but a terminal (at least when not redirected).  Terminals are a
subtype of character-special devices, and have no limitations on block
boundaries for accesses.

--
Eric Blake


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