> Date: Thu, 7 Mar 2013 05:43:29 +0100
> From: pan cake <cake.pan4@...>
> >> C:\WINDOWS>dd if=\\.\D: of=\\.\F:\sdcard
> >> dd: opening `\\\\.\\D:': No such file or directory
> > Does the following work? Don't know I've never used dd on Windows.
> > dd if=//./D: of=//./F:/sdcard
> No, this doesn't work unfortunately.
I suspect that the \\.\D: names only work if you use DeviceIoControl
to read the data, and it probably also requires some non-default
privileges and some other quirks. See these two places for more
(And note that the 2nd one has some obscure blurb about FAT
filesystems, which I suspect is what you have on the SD card, so
I doubt the ported dd goes to any of these length to implement direct
access to block devices.
In any case, the second argument does not need to use the \\.\F:\foo
> This said, I also stumbled upon
> saying unc paths are not usable on command line.
That's not what that page says. It actually says something that seems
to confirm my guess above: that you need to use DeviceIoControl to
access devices whose handles you get by opening \\.\D: and such.
And in any case, there's a big difference between submitting URLs to
CMD's internal commands, and submitting them to other programs via CMD
command line. Any such limitations of CMD do not have to affect
programs invoked by CMD.
> This is my second dissapointment with linux tools on windows. I
> switched to msys after gnuwin32's find.exe hat troubles skipping
> pagefile and hiberfile just because they are locked by the system
> while other programs managed to do that well.
GnuWin32's port of Findutils is badly broken in more than one way.
Try the one here (it does catch pagefile.sys, at least on my system):
> And now dd.exe,
> apperently ported to windows is not able to access a partition. If the
> sources were not on sourceforge, where each click for viewing any file
> is a pain or at least on the mingw site it had pointers to the dd port
> source code so I could navigate there easily I would have had a look
> into it by now. But besides vim on windows I'm kind of getting
> frustrated about linux tools on windows. Let the linux tools maybe
> having problems on windows aside, not even the windows documentation
> is friendly enough to help me understand how things work over here so
> I can do anything useful with device namespaces.
Welcome to Free Software, where you are on your own. (And if you
think the documentation problems are specific to Windows, think
Anyway, making a good Windows port of a non-trivial package written
for Posix platforms is a formidable task. These packages, especially
those which access files, devices, and directories in non-trivial
ways, are chock-full of assumptions that simply don't hold outside of
Posix world. Like that you can delete a file while it is still open,
for example, or that you can open a device and read from it using
'open' and 'read'. Making it all work on Windows, even when it is
possible, takes much more than just compiling the sources and
#ifdef'ing away or replacing missing functions.
So you should actually _expect_ these corner cases not to work in
Coreutils are notorious for such problems, btw.
> So the things I learned are win32 device namespace is different from
> the file namespace, accessible via '\\.\ which is different from \\?\,
> I can check winobj for symbolic links and basically the registry has a
> MountedDevices key, there are GUID's for each device and lots of lots
> of little puzzle information like this but still I can't figure out
> how to get dd work on windows.
> My dissapointment is big.
Maybe you could sit down and produce an improved port. That's what I
did when I saw so many missing and broken ports, which is how
http://sourceforge.net/projects/ezwinports/ was born.