Hello,
I want to report something, that really makes me not use Copy Handler.
I just copied my old HDD (more than 1TB) to a fresh HDD (both NTFS). I decided to copy the files and not to clone, because the old drive was a little bit fragmented and I wanted a fresh start.
As im used from copying with Windows explorer it just copies file bye file, and they not fragmented afterwards. But not with Copy Handler....I get terrible Results. See the attachments. My sourcedrive has only 300 fragmented files. But on the fresh drive, Copy Handler copied on, their are 26705 fragmented files. To be honest its totally fragmented afterwards, so Im going to copy all files again with Windows explorer. Man thats a senseless worndown of my drive, if I knew that before, I would never use CP >:(
See this as critic, bugreport....or tell me why this could be normal!
revnu
Anyone active here that wants to discuss this topic?
What to say? The same problem. I just copied 3 large files, one after another, and every time it occupied a block and then the other blocks very far from the first. I'm looking for a solution, with or without CH.
Update: it seems that supercopier has an option to preallocate disk space. http://ultracopier.first-world.info/supercopier.html or maybe the newest ultracopier
This is actually a symptom of the way the operating system is handing the data, not the program itself.
When you enable multi-threaded transfers, the target operating system writes data as it received/buffered/flushed. Windows doesn't care where it puts it on the drive, as long as it can get it out of the write buffer fast enough based on where the platter heads are located on disc. SSD's don't have this problem because access latency isn't an issue.
If CopyHandler had a Client/Server Mode, then it could control the way in which data flows to the disk per thread by controlling the flush sequence of the write buffer. You would have to run the software at the source and the target for a function like this to work, as Windows is too stupid to do it correctly.