Jump to content

UDF-formatted hard disk drives under Windows 98


Multibooter
 Share

Recommended Posts

What software would you recommend for wiping only the beginning of the HDD?
dd in Linux.
dd if=/dev/zero of=/dev/sdb bs=1M count=16

will copy 16 blocks of 1MiB from /dev/zero (an infinite source of zero's) to /dev/sdb (second harddisk)

Thanks Mijzelf, thanks dencorso

Linux seems to be the easier way for wiping the initial part of a HDD. More about it a little later.

Experimenting with MBRWizard v4.0.135 on track 0 of a UDF-formatted HDD

MBRWizard v4.0.135 has a very easy interface. With a command line program, in contrast, it's probably a little easier to make mistakes, like wiping the wrong disk. Unfortunately MBRWizard v4.0.135 does not run under Win98SE, though I have not yet tried it with KernelEx.

I just backed up under WinXP with MBRWizard v4.0.135 track 0 of the 80GB UDF-formatted HDD (no partition table), then deleted track 0 on this HDD with MBRWizard. I then connected this UDF-formatted HDD to the Ubuntu computer - and lo and behold: Ubuntu read the UDF-formatted HDD just like before, and the test .jpg file on it displayed fine. I then copied under Ubuntu a 2nd test .jpg file onto the 80GB HDD (no partition table, wiped track 0).

I then connected this 80GB UDF-formatted HDD (no partition table, wiped track 0) under WinXP and restored with MBRWizard the backed up track 0 (created before the addition of the 2nd test .jpg file under Ubuntu). Both test .jpg files on the UDF-formatted HDD displayed fine. So it looks like Ubuntu does not care what is on track 0 of a UDF-formatted HDD.

Edited by Multibooter
Link to comment
Share on other sites


Formatting an 80GB HDD to UDF 1.02 with Ubuntu

Terminal in Ubuntu displays the following when formatting an 80 GB HDD to UDF:

Disk /dev/sdb: 80.0 GB, 80026361856 bytes

255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x1b0e8f7e

Device Boot Start End Blocks Id System

omnibook@OmniBook-PC:~$ sudo mkudffs --media-type=hd --blocksize=512 --udfrev=0x0102 /dev/sdb

start=0, blocks=64, type=RESERVED

start=64, blocks=12, type=VRS

start=76, blocks=180, type=USPACE

start=256, blocks=1, type=ANCHOR

start=257, blocks=16, type=PVDS

start=273, blocks=1, type=LVID

start=274, blocks=156300957, type=PSPACE

start=156301231, blocks=1, type=ANCHOR

start=156301232, blocks=239, type=USPACE

start=156301471, blocks=16, type=RVDS

start=156301487, blocks=1, type=ANCHOR

Comparing the listing here for the 80GB HDD, and the listing for the 2TB in posting #49 it looks like there is a bracket around PSPACE, 274 sectors in front and 257 sectors at the end, but restoring these sectors at the beginning and at the end is not sufficient to restore data after formatting the UDF-HDD to FAT32.

Edited by Multibooter
Link to comment
Share on other sites

I think jaclaz would suggest getting the DSFOK utilities and using something like the following command sequence (under XP):

Normally, yes :yes: .

But since Multibooter is already on the "dd bandwagon" :angel , he (and you ;)) might find this thread interesting:

http://reboot.pro/15207/

And since you are both very nice guys, a SCOOP :w00t::

https://github.com/bmatzelle/gow/wiki/

rigorously UNtested by me, though :ph34r: .

jaclaz

Link to comment
Share on other sites

But since Multibooter is already on the "dd bandwagon", he (and you ;) ) might find this thread interesting:

http://reboot.pro/15207/

I think anyone who wants a 'simple' Windows version of dd, is doomed, just because it can't be done. On *nix, dd is a quite simple and small (54kB on my box) utility, and that can be done because dd only needs to know 1 single trick: Copy one or more blocks of data from one file to another. On *nix everything is a file, a disk can be treated as a file, and so can a partition, or a regular file (duh!), and something like /dev/zero is just a file, which will return zero's on each read, no matter how big the blocksize or from which start position. Oh, and stdin and stdout are pipes, and so also files, so you can also read from, or write to a pipedevice.

Storing and restoring a parition to a zipfile:

dd if=/dev/sda1 | gzip >sda1.zip
gzip -d sda1.zip | dd of=/dev/sdb1

But in windows all these kinds of devices have different ways of open, read and write, so dd has to recognize each device you offer him, and know the way how to access them, creating a big and complex executable, or it has to lean on a complex compatibility layer, like Cygwin.

Link to comment
Share on other sites

I think anyone who wants a 'simple' Windows version of dd, is doomed, just because it can't be done.

Well, the referenced thread contains links (and also personal opinions :whistle: ) on several ports of dd for windows, including a few ones MUCH "simpler" (and "smaller") than the CYGWIN version, so, not only it is perfectly possible but it has already been done, by several people, including - curiously a version that includes a /dev/zero device and of course piping is perfectly posible on NT systems.

I am clearly missing your point. :unsure::ph34r:

jaclaz

Link to comment
Share on other sites

In that case I misunderstood your intention. The first link is (in my eyes) a blog about the search to a small port of dd, without huge dependencies. Conclusions:

Will any of you create a compiled dd.exe that:

  • needs NO external .dll's
  • has NO "convert" options
  • an access Physical devices both read and write
  • has an internal /dev/zero
  • it is smaller than the mentioned ones (ideally below the 40 Kb mark)

Doesn't seem the author thought he had succeeded.
curiously a version that includes a /dev/zero device
Curious indeed. The device is needed to zero out any output file of dd. But the simple fact that it's needed to include it makes the executable more complex, and also shows the shortcoming. How about /dev/random?
and of course piping is perfectly posible on NT systems.
Yes, NT supports piping, and a Windows port of dd likely also. But the ecosystem mainly doesn't. So where can I pipe from/to? A mayor strength of dd (and most commandline tools) in *nix is that it can be piped with many other tools, adding amazingly much functionality. Want to fill a disk with 0xFF?
cat /dev/zero | tr "\000" "\377" | dd of=/dev/sda

It's all just available.

Link to comment
Share on other sites

In that case I misunderstood your intention. The first link is (in my eyes) a blog about the search to a small port of dd, without huge dependencies. Conclusions:

Will any of you create a compiled dd.exe that:

  • needs NO external .dll's
  • has NO "convert" options
  • an access Physical devices both read and write
  • has an internal /dev/zero
  • it is smaller than the mentioned ones (ideally below the 40 Kb mark)

Doesn't seem the author thought he had succeeded.

Yep :), but the conclusion is NOT that one, that is a "final question", actually just some poking at the good Linux guys on reboot.pro :blink: .

The conclusion is ABOVE that.

And it says:

Meet PLDD :

http://home.comcast.net/~plavarre/plscsi/tools/pldd/

self-standing, biggish (pldd.exe 63,488 bytes) BUT includes a "timeout" and more than that the equivalent of a /dev/zero.

curiously a version that includes a /dev/zero device
Curious indeed. The device is needed to zero out any output file of dd. But the simple fact that it's needed to include it makes the executable more complex, and also shows the shortcoming. How about /dev/random?
and of course piping is perfectly posible on NT systems.
Yes, NT supports piping, and a Windows port of dd likely also. But the ecosystem mainly doesn't. So where can I pipe from/to? A mayor strength of dd (and most commandline tools) in *nix is that it can be piped with many other tools, adding amazingly much functionality. Want to fill a disk with 0xFF?
cat /dev/zero | tr "\000" "\377" | dd of=/dev/sda

It's all just available.

About zero and random, see here :whistle: :

http://www.ltr-data.se/opencode.html/#ZeroDrv

You can pipe dd to gzip under NT allright, that is what you originally posted :yes: .

And if you read attentively the thread, you wll also see how I advocate the need of a NT version of mkfifo...

Now :), this is not intended as a NT vs. Linux debate, rest assured that - limited to dd-like and connected operations, I know enough of both "worlds", and know which environment is "better" or "more convenient " to carry on the small tasks I normally need to do, and use the one or the other as I see fit..

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

  • 1 year later...

Big bump, I know :), but I happened to find - while looking for *something else* - a Toshiba UDF driver for XP (both 32 bit and 64 bit):

http://wp.xin.at/archives/829

which may possibly :unsure: solve the issues that KB321640 :

http://support.microsoft.com/kb/321640/en-us

completely FAILS to solve.

Rigorously UNLIKE tested :w00t: (not the 32 bit, nor the 64 bit :ph34r: one), reference is just for info.

jaclaz

Link to comment
Share on other sites

Er... jaclaz... don't look now but... this is the 9x/ME forum... right?

Sure :), and between 3/4 and 4/5 of posts reference Linux, NT and XP, besides 9x/Me :yes: (and even Vista :ph34r: and 7), the differences between them and even include notes about use of dsfok (under NT based systems), of dd (under BOTH Linux and NT based systems), and some more generic dd philosophy.

You might appreciate how I did not post a link to something really off topic, such as antigravitory cats :

D@mn! Look at what you made me do! :blushing:;)

Yes, it shouid be the same, though MDGx seemingly found only the 32 bit one.

A good question (that we cannot ask here ;) ) would be "Who is actually running the XP 64 bit version?"

jaclazDUCKEMOTICON_FINAL.gif

jaclaz

Link to comment
Share on other sites

  • 6 years later...

DVD Write Now's driver's source code is at https://github.com/reactos/reactos/tree/master/drivers/filesystems/udfs. Its not showing the UDF formatted disk image's contents in either ReactOS or Windows Server 2003. I formatted it as UDF via Windows 7's format command. Maybe someone here can fix it.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.


×
×
  • Create New...