Re: Extracting files off “unknown” 8 inch disks. Any thoughts…
cclist at sydex.com
Fri May 5 14:46:38 CDT 2017
On 05/05/2017 12:20 PM, Fred Cisin via cctalk wrote:
> This is a rare occasion that I will disagree with Chuck.
I'm fine with that. Let a thousand flowers bloom...
> Yes, there are situations, where the file system is unknown or not
> understood, where the best approach is to copy all of the sectors and
> then let the client determine the rearrangement of those into the files
> that they want. I've done that - both with having my junior staff wade
> through them looking for probable sequences, and even handing the client
> a giant stack of printouts and letting them decide (and then I
> concatenated the goups of sectors that they wanted)
I didn't mean what I think you thought I meant. The immediate problem
is getting data--any data at all. If you can retrieve every sector on
the disk, then it's just a matter of software to unravel the filesystem.
DEC filesystems in general are pretty well documented, even if you have
to wade through the strangeness of things such as RAD50 file names.
Yes, flux-transition (e.g. catweasel) tools do exist for RX02
double-density reading and writing. I've used them in the past. At
least one runs under Linux and allows one to copy dd-style sector by sector.
But first you need the bits. Without those, the filesystem is just a
When I retrieve specialized formats (e.g. 8" closed-caption (WGBH)
disks), I acknowledge that there's a lot of guess-and-by-gosh to
unraveling them as no documentation seems to be extant. I'll always
include a "raw" sector-by-sector image as well as my
interpretation/translation. Similarly, for things like Brother 120K and
240K floppies, I keep the flux-transition recording around for future
reference until the customer signals his satisfaction.
Sometimes the filesystem organization is well documented, but the disk
has been corrupted (you see this with Apple HFS floppies and hard disks
more than you'd think) and you have to extract data without the benefit
of the filesystem structural information, piece by piece. It's a manual
process and fraught with error. So you keep the "raw" image around in
case the inevitable happens.
Data first--interpretation later.
More information about the cctalk