Am 17.05.15 um 09:06 schrieb supervinx: Have a look at the dd(1) options "noerror" and "sync". -- tsch??, Jochen

IF they are just plain old DOS format (DD or HD), then COPY will do. IF they are just plain old DOS format (DD or HD), then there is no reason to "image"! IF they are just plain old DOS format (DD or HD), then the files are all that matters. IF they are NOT just plain old DOS format (DD or HD), THEN there might be reason to image, such as if they are some unknown and not understood format, and the files can not be extracted, or there is reason to believe that there is some form of information in the structure and format of the disk that should be preserved, such as system tracks on CP/M disks, etc. Or, if they are copy-protected, and stuff other than the files needs to be preserved to be able to use the files. 'Course then, your "imaging" methods are not likely to work, anyway. But, IF they are just plain old DOS format (DD or HD), then there is NO information other than the file content on the disks. If you format a 3.5" disk in a DOS/Windoze machine, and copy some file onto it, . . . Could you please explain to me WHY you would want an "image" of that disk?

On Mon, 18 May 2015, andrew clarke wrote: Good point! Unless the disk has some special weirdities, that is easy enough. For sets of disks, I like to determine whether the disk breakdown is essential. For something like Windoze, putting all of the disk contents into a single directory can be handy, but for some other packages, I prefer to put the files of each disk into a separate subdirectory, and use the volume label as the name for that subdirectory. Unless the DOS version of the copies produced doesn't matter, . . . I wrote out the steps in DEBUG to copy the boot-sector (I hope that I didn't screw up and type it in wrong!) Yes, most versions of DOS require the 2 hidden files to be in specific places on the disk AND in the DIRectory, by copying them first. Early versions of the SYSTEM program will only install the same version as what is running, so that will often not be an option. It's easy, if not paying attention to forget to copy the hidden files, or not realize that some INSTALL program is overly dependent on volume labels, etc. It all tends to come back to whether what's needed is the disks themselves, or the information stored on them. And once everything is copied to the Brainspawn's InfoSphere, (Only twice the size of three regular DataSpheres) none of the originals will still be needed. Nevertheless, unless there is reason to do otherwise, I'd rather simply copy the files and when recreating, simply create a new system disk to put them on, IF NEEDED. And, unless it is NOT "normal" standard stuff, I still don't see a reason to "IMAGE" ordinary stuff. BUT, of course, if the original poster is NOT talking about DOS disks, then imaging may be truly essential. With Don Maslin gone, it could be a major hassle trying to find a boot disk for an Amada, Jonos, Sony M35 CP/M, etc. BTW, I still have difficulty with calling 3.5", "EARLY"! -- Grumpy Ol' Fred cisin at xenosoft.com

On Sun, 17 May 2015, Fred Cisin wrote: Oh man, what about deleted files? Unallocated sectors with perhaps interesting data? Boot sector? Wrong. Christian

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) On Mon, 18 May 2015, Liam Proven wrote: [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