Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Jul 2012 15:12:59 -0500 (CDT)
From:      Robert Bonomi <>
Subject:   Re: fsck on FAT32 filesystem?
Message-ID:  <>
In-Reply-To: <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

> From: Polytropon <>
> Date: Sun, 22 Jul 2012 18:14:02 +0200
> Subject: Re: fsck on FAT32 filesystem?
> By the way, I remember I had a DD.EXE program on my old DOS
> system. I'm not sure if such a tool could operate on devices
> (instead of filesystem-based representations as "drive letters"),
> but it actually _was_ a DOS-based "copy & convert" utility
> for the PC. :-)

MSDOS/PCDOS had -no- O/S functions to directly access actual disk
devices.  The ONLY fuctionality provided to the user, by the "O/S"
was filesystem based access.  To get 'raw' device access, one had 
to bypass the O/S entirely, and use direct BIOS calls (INT 13h).

And, _if_ you went the INT 13H route, you had to include your own custom
code in your app for MS 'partition' handling, and possible multiple logical
drives inside a single 'extended partition'.

There was a fairly widely available "INT 13H" program called 'rawrite"
that would copy a file (inside the filesystem on a letter-named drive)
to a raw disk device.  Commonly used for making bootable UNIXesque floppies
under DOS/Windows, from an 'image' file.  There was a companion 'rawread',
that was much less widely distributed -- few people needed to make a
complete disk image file of a physical drive (or logical 'drive letter')
under windows.

Rawread/rawwrite would work for 'cloning' a *SMALL* physical drive, but *ONLY*
if the 'bad sectors' were in the same place(s).  They _weren't_ smart enough
to write the data intended for what turned out to be a 'bad sector' on the 
target drive to "somewhere else", and update the FAT accordingly.  They only
worked on small drives because they only spoke 'CHS' sector addressing, not

Want to link to this message? Use this URL: <>