SMF - Just Installed!

Main Menu

"Copy rest" dangerous?

Started by gabmatrix, February 10, 2009, 03:08:35 AM

Previous topic - Next topic


Hi there,

I began using Copy Handler a few weeks ago and I was using the "Copy rest" as a way of telling "Copy the difference between this new file and the old one".

However, I recently experienced a problem with doing that. I did "Copy rest" on a TXT file and it corrupted the destination (My inserted text wasn't there and there was some garbled text at the end). I then understood that the "Copy rest" feature is for unfinished move/copy operations. Fortunately, I was able to undelete the file I just moved.

I think the "Copy rest" could be a great time saver in rare situations but it can be a very dangerous command. I never thought that a copy command could end in a different result than either the source or destination. I see this as a problem, assuming this is not a bug.

What do you think?



The name 'copy rest' should suggest that only the rest of file is to be copied. CH does not inspect the file format at all - for those things there are tools like WinMerge and so on. Instead CH treats all files as binary ones.
Of course you can say it's dangerous, but the same thing applies to overwriting file, which can cause data to be lost. It does not mean that those functions should work any other way.

But what do you think the solution to this problem would be?


I understand what you mean...

First, I'm wondering when do we need this "Copy rest" feature? If I just cancel a file transfer, the destination file gets deleted. So the only way I can see this feature useful is if my computer or software crashed. In today's computing world, that is quite rare as systems are usually pretty stable.
So the feature shouldn't be used often right? So maybe it should'nt be the second button?

Maybe I would see this "advanced" feature in a sub-menu with some kind of warning the first time we use it or just put a red exclamation point before it. I don't know, I'm just trying to think here.

That's just my personal thoughts...


I'm afraid that the file does not get deleted when you cancel the transfer (at least if I remember correctly). There is also pausing that could lead to the overwrite/copy rest prompt. When you copy multi-gigabyte files using some slow hardware/network it is quite useful to be able to pause the transfer and then resume it at the place where it stopped.


Cancelling a file transfert is supposed to delete the destination file. Why should I want the incomplete file to remain there? That's the whole point of cancelling the transfer. And that's why Windows's traditional copy does it like this.

I haven't tested in CopyHandler but it should behave the same if it doesn't. I don't want to do 2 actions (cancel and delete) to cancel a file transfer.

IMO, I think this feature should exist but not by default. We should be able to specify if cancelling a file tranfert delete or not the file. Also, the "Copy rest" should not be the second button because, as explained in my previous post, it can lead to unexpected result if used incorrectly.

The developers can decide what they think is best, I just wanted to share my experience.


The 'Copy rest' command is the most usefull function of Copy Handler and the function I use the most. I use Copy Handler to copy files from a large network to my computer. As I have no idea if the computer on the network will remain online during the entire copy operation I love the way Copy Handler lets me finish my download at a later time, or complete it from another source. If it were more difficult to use the 'Copy rest' command I'd stop using Copy Handler.
To prevent your problem it might be usefull to give a short introduction to the program after installation. Ie. a screen that explains the general purpose of the program and explains it's most used functions.


I agree, this tool is very useful if transferring from a network share. You never know when the network is down for 10 minutes or 1 hour.
HC will let you continue at the point it was lost.

I like it.

SMF spam blocked by CleanTalk