[dencorso]

For each issue, the right tool. Here XXCOPY is the tool of choice (for file-based cloning).
Of course it can be done with XCOPY, and possibly in many other more difficult ways.

@jaclaz - Here's what the current point of this discussion reminds me of...

Quote

jaclaz, on 27 November 2011 - 12:48 PM, said:

@dencorso
Comeon , you know better than suggesting to wipe a whole hard disk, and WHEN this is needed, to suggest anything but the internal ATA commands....
We have at least one report:
http://reboot.pro/13601/
http://reboot.pro/13601/page__st__87
that a "same" 250Gb drive took 85 minutes vs. around 210 (using DBAN)
It yould be interesting if you could do a comparison test of the ATA command and Active Kill Disk (dos extender) on any "spare" disk you may have handy.
JFYI, a carpenter's comparison :
http://reboot.pro/13601/page__st__46

dencorso, on 27 November 2011 - 07:55 PM, said:

jaclaz *is* right (of course, as always!): HDDErase is faster than Active KILLDISK. The latter remains useful when one wants to zero out just some parts of a HDD, but HDDErase is way faster for a full disk wipe, and the results are equivalent.

[jaclaz]

dencorso, on 08 June 2012 - 02:07 PM, said:

For each issue, the right tool. Here XXCOPY is the tool of choice (for file-based cloning).
Of course it can be done with XCOPY, and possibly in many other more difficult ways.

... and possibly im many more as simple ways.
XXCOPY is also IMHO an exceptionally goot tool, but it is not the only option, just as an example Xclone would most probably do :
ftp://ftp.sunet.se/p...tl/xclone13.zip

dencorso, on 08 June 2012 - 02:07 PM, said:

@jaclaz - Here's what the current point of this discussion reminds me of...

I don't see the actual connection , in that case I gave you a report about a tool found to be a MUCH faster way (and JFYI "not-really-equivalent" as hdderase will also wipe a few sectors not normally accessible by external software, so also "better"), I may well be wrong, but I don't think that there are great speed differences when using XXCOPY vs XCOPY vs. XFILE vs. XClone vs. *whatever*, in the sense that any "file based" tool will take more or less the same time.
XXCOPY Author confirms how the program is not particularly tuned towards "speed" (at least no for a "bulk copy" as the one we were talking about:
http://www.xxcopy.co...sg/msg00189.htm

but the context of that thread:

jaclaz, on 27 November 2011 - 12:48 PM, said:

The WD utility will wipe anyway enough data, at the minimum first and last million sectors:
http://www.msfn.org/...ros-with-wd-dl/

You don't actually need to 00 out anything but the first (say) 100 sectors.

Anything else is overkill, including the WD utility and ActiveKill disk.

If you want to completely wipe a disk use the secureerase utility:
http://cmrr.ucsd.edu...cureErase.shtml
that will use the internal ATA commands and will be faster than *any* software based solution.

Was that what was actually needed was maybe to wipe the first handful of sectors and instead it was suggested to wipe the whole disk and suggested a slowish tool to do this completely unneeded thing .


jaclaz

[dencorso]

With all due respect, and with thanks for the pointer to the interesting xclone13, whatever other options you may come up with, we still have just three cases, really (provided we limit ourselves to file-based cloning):

XXCOPY: the most well-known, still developed, still supported, widely used and very thoroughly debugged, 3rd-party tool adequate for the job.
XCOPY: the tool available with the OS, that is known to be able do the job (and reasonably well test-demonstrated to work as intended).
OTHERS: everything that is not those two above, but that can probably do the job, although much less test-demonstrated to work as intended, if at all.

[jaclaz]

dencorso, on 09 June 2012 - 05:31 PM, said:

..... we still have just three cases .....

...and some wise philosophy :

Ray Bradbury said:

Life is "trying things to see if they work".

jaclaz

[mh84]

Guys thanks for the helpful discussion but if you are still interested in my solution then I switched from SATA to IDE to avoid problems. Thanks for help anyway.

[jaclaz]

mh84, on 10 June 2012 - 05:05 AM, said:

Guys thanks for the helpful discussion but if you are still interested in my solution then I switched from SATA to IDE to avoid problems. Thanks for help anyway.

Good , the main thing is that you found a suitable way out from the issue .

Unrelated , but not that much , maybe this is an option:
http://www.msfn.org/...s-whichwhatwhy/

jaclaz

[jumper]

I realize that cloning a drive is no longer topical, but how about simply dragging the source drive (C:) icon onto the destination drive (D:) icon?

4. Clone a Windows system to the Hyperdrive by dragging and dropping the desired Windows system icon onto the Hyperdrive RAM icon.

Just drag the image of your hard drive over to the icon for the external drive, and everything will be copied.

[jaclaz]

jumper, on 12 June 2012 - 10:22 PM, said:

I realize that cloning a drive is no longer topical, but how about simply dragging the source drive (C:) icon onto the destination drive (D:) icon?

4. Clone a Windows system to the Hyperdrive by dragging and dropping the desired Windows system icon onto the Hyperdrive RAM icon.

Just drag the image of your hard drive over to the icon for the external drive, and everything will be copied.

Sure , first thing you need to find - WITHOUT installng Hyperdrive and HyperOS - the "My other computers", then it is simply a matter of having something you DID NOT install and DO NOT have, actually clone your drive :

Quote

Having connected the HD4 to your PC the simplest way to get started in the case of Windows 2K/XP is as follows...

0. Make sure that the BIOS sees the HyperDrive and that the BIOS Hard Disk Boot order is correct!

1. Boot the PC and install HyperOs OneClick or HyperOs 2007 Geek/SuperGeek on your C: drive.

2. Open My Other Computers.

3. You will see the HyperDrive partition marked with a RAM icon.

4. Clone a Windows system to the Hyperdrive by dragging and dropping the desired Windows system icon onto the Hyperdrive RAM icon.

5. Click OK. HyperOs will clone that Windows system to the HyperDrive and then reboot.

6. Double Click the HyperDrive RAM icon and click OK. HyperOs will swap to the cloned Windows system on the Hyperdrive.

jaclaz

[jumper]

The intersection of the content within my two links is "drag one icon onto the other."

I read years ago that this is the easiest method to clone a drive. I don't remember if what I read pertained to Win3.x, Win9x, or WinXP.

My question is: Does anyone happen to know if the icon drag-and-drop method for cloning a drive will work in Win9x, including preserving short file names?

[submix8c]

Drag-And-Drop is COPY!!!!!! Via "Temp" Folder! Period!

[jumper]

submix8c, on 13 June 2012 - 04:22 PM, said:

Drag-And-Drop is COPY!!!!!! Via "Temp" Folder! Period!

Yes, we are talking about file-based cloning. Beyond that, I fail to see how this is relevant to my question.

I'm not asking anyone to do any tests, I'm just wondering if anyone actually knows.

When I get some time, I'll put some files with long names (that have conflicting short names) on my ramdisk and clone it to a flash drive (or floppy or another ramdisk) using this drag-and-drop, icon-to-icon method. If all names match (long and short), I'll do some renaming and retesting in an effort to get it to fail.

Slow method? Yes. Easy method? Yes (if it works). Third-party app required? No--just what's already there.

[dencorso]

One of the things that are not guaranteed, when one does plain copy, is whether the short filenames created on copy will be associated to the same long-filenames as they are in the original source. This problem is well discussed in one of the XXCOPY knowledge base documents I gave a link to in one of my previous posts to this thread. Then there's the question of how hidden and super-hidden files will be treated...

[rloew]

jumper, on 13 June 2012 - 08:07 PM, said:

submix8c, on 13 June 2012 - 04:22 PM, said:

Drag-And-Drop is COPY!!!!!! Via "Temp" Folder! Period!

Yes, we are talking about file-based cloning. Beyond that, I fail to see how this is relevant to my question.

I'm not asking anyone to do any tests, I'm just wondering if anyone actually knows.

When I get some time, I'll put some files with long names (that have conflicting short names) on my ramdisk and clone it to a flash drive (or floppy or another ramdisk) using this drag-and-drop, icon-to-icon method. If all names match (long and short), I'll do some renaming and retesting in an effort to get it to fail.

Slow method? Yes. Easy method? Yes (if it works). Third-party app required? No--just what's already there.

Not only is it necessary to create conflicting short names to get ~2, ~3 etc. but they have to be out of order in the Directory so that xxxxxx~2 comes before xxxxxx~1 in an unsorted Directory.

The following should do the job:

1. Create a new Folder x
2. Copy a file to x\aaaaaaaaa1.
3. Copy a file to x\aaaaaaaaa2.
4. Copy a file to x\aaaaaaaaa3.
5. Delete file x\aaaaaaaaa1.
6. Delete file x\aaaaaaaaa2.
7. Copy a file to x\bbbbbbbbb.
8. Copy a file to x\aaaaaaaaa2.
9. Copy a file to x\aaaaaaaaa1.

The source file can be anything, preferably small.

[jaclaz]

jumper, on 13 June 2012 - 08:07 PM, said:

When I get some time, I'll put some files with long names (that have conflicting short names) on my ramdisk and clone it to a flash drive (or floppy or another ramdisk) using this drag-and-drop, icon-to-icon method. If all names match (long and short), I'll do some renaming and retesting in an effort to get it to fail.

With all due respect , a rather pointless experiment.
The idea is (was) to "clone" a drive where a bootable Win 9x OS was residing to another drive and have this latter boot that OS "as before".
Copying a bunch of files to a ramdisk is - even if sudccessful - only a subset of the needed chores.

jumper, on 13 June 2012 - 08:07 PM, said:

Slow method? Yes. Easy method? Yes (if it works). Third-party app required? No--just what's already there.

As said, a lot of time have passed, so I cannot remember the details, but at the time the XCOPY approach already posted was used because no third party tools were needed and because the simple COPY did not work, AFAICR.

jaclaz