3.5 floppy imaging

[Fred Cisin]

It seems that each person has a unique idea of the goal(s).
There are some discrepancies in our perception of this elephant,
based on whether the interest is in information, data, or chaos,
whether the content is to be used in a different situation than
the original (including emulation systems) or reuse in a situation
identical to the original, and what level of exactitude is desirable
in reproduction.
(and, of course, I have encountered academics who would rather scan a 
photograph at 200dpi and then store with LOSSLESS compression rather
that a scan at 1200DPI stored with LOSSY compression)


>> IF they are just plain old DOS format (DD or HD), then COPY will do.

On Mon, 18 May 2015, Liam Proven wrote:
> No it won't -- for a start, it won't do subdirectories, nor hidden files.
[If just nitting, then well done!]

Well, agreed that it won't necessarily be the best choice, but that is 
implicit in "will do".
It certainly will do subdirectories, simply by including them in the 
filename.  BUT, it won't walk the tree for you; YOU have to do that.

The specific advantage of COPY "will do" is that it is an internal
command in all versions of DOS.  It is always there and available.
If for some reason you want to boot with one of those subject disks,
then it will be there, even if there are no other DOS utility programs
available on that disk.

OTOH, if you DO have a complete suite of DOS utilities, then consider 
XCOPY  (/E/S/V is good for this)  That will walk the tree.

If you have a good collection of third party utilities, then you may have 
many better choices available.

"WILL DO" is in reference to the fact that ANY time that MS-DOS is 
running, COPY is available, and "will do", even if there are other
choices that might be preferable.
NOTE: CP/M does not have such a command internal - PIP is a program
that may or may not be around when you need it.

NOTE: for both XCOPY and versions of COPY that support it,
/V  is often misdocumented as "verifies that files are copied correctly".
It does NOT confirm that the content of the destination file matches the 
content of the source file.  Instead, its sole purpose is to confirm that 
the sectors of the destination file are readable, with correct CRCs, using 
a meaning of "VERIFY" similar to the FDC command and what is done by the 
FORMAT program.


It turns out that many here are interested in DISK IMAGES, far more
so than the data on the disk, and the information that it contains.
I apologize to any and all concerned for my presumption that that
was the focus.  I tend to think of the words of the author being
what matters, rather than the overall product.  Some of that
relates to the days when the desired result was A FILE, rather
than a SET of files of which one might not even be aware of some
secondary "support" files.


And, of course, there are some people who feel that the disk is not 
adequately "archived" without all of the "forensic" content.  Some
people may have legitimate need for data far beyond the information
that the user had "saved" onto the disk.
They may want to examine deleted files, and content of sectors
that may no longer even be associated with any current or intact
deleted file.
What about off track residual content after a sector has been
rewritten? 
There may be reasons to care about what fill pattern had been used
in formatting (not always E5), and to examine the size, structure,
and content of inter-sector gaps. When a sector is rewritten, there
can be write splice glitches (hence the reason for sync fields);
are weinterested in them?
Should we care about defects on the disk, other than trying to
work around them?
We may need some of that "forensic" data if analyzing a
copy-protected or otherwise non-standard disk.
(note that I had explicitly included a caveat about "NORMAL"
and/or "plain old", since I was NOT including forensic analysis)


We all have different goal(s).
IFF our goal is to be able to "reproduce" the disk, then surely
we need to define whether we mean a "duplicate" that behaves the
same (file access), or whether we want to make it match on a lower
level - DO I NEED TO WRITE THE DUPLICATE ON A WABASH DISK??


--
Grumpy Ol' Fred     		cisin at xenosoft.com