[Pkg-mc-devel] Bug#592941: Bug#592941: mc: interrupted move causes duplicated files

[Yury V. Zaytsev]

Hi!

I don't think it's a bug. This behavior have been there for ages and I
think for a good reason. Let me clarify it below:

On Sat, 2010-08-14 at 12:43 +0200, Adam Borowski wrote:
> 
> This causes duplicated files, and is especially painful when information
> about what has been moved and what not is important. All that MC offers is
> restarting the move from the very start, which is not a good idea for large
> transfers over slow links.

Not true. When you start the move again, on the first already existing
file mc will stop and warn you. There is a number of options available:

Overwrite all targets? [ All ] [ Update ] [ None ] [ If size differs ] 

"Update" will only overwrite files the date of which is older than those
that are being moved or copied, "If size differs" will overwrite all the
target files that have different size than the source files.

The latter is what you need to continue the process properly by leaving
alone the files that already have been moved and moving only those that
haven't been moved already.

If you need the information on what has been moved already and what not,
you need the Compare directories to function properly (recursively).
There is a ticket for this in upstream bugzilla.

> Also, while such postponed deletion does improve performance for small and
> medium moves, it seriously degrades it when the tree is big enough to not
> fit in the VFS cache.

How bad is this performance decrease?

> Thus, a change I'd suggest is:
> * don't postpone more than, say, 1000 deletions
> * on an interruption, delete the pending completed files before aborting
> (the former may seem tangential, but in a tree that takes 10 minutes to
> delete, you don't want to block for long before displaying the error message)

I'd suggest not messing with deletions if the action that the user
requested has not been successfully completed in full. Maybe it will
give you some (arguable?) performance gain in your very specific case,
but will break other reasonable usage scenarios. I think you just need
to use "smart" resume strategy (overwrite if size differs) and Compare
directories when it will be fixed.

In what concerns a usage scenario that will be broken by your suggested
change: 

1) Imagine that I want to move a big tree to an FTP. In the middle of
the operation remote server ran out of space and the transfer failed.
Successfully transferred files have been deleted.

Now there's not much I can do with this remote FTP. I found another
location to upload them. I have to download them first, then re-upload
the whole package to the second server. I'm screwed.

2) I started moving a huge tree to another disk and half-way realized
that it's the wrong volume. So I abort the move, but screw it, half of
the collection has already been deleted from the source drive.

Now I have to move it back and only then move to the correct drive.

---

I suggest to close this as wontfix, because I really have to make mc do
any destructive action before the requested command has been completed
the way the user wanted it to in full and without problems.

I hope you can understand my point.
 
-- 
Sincerely yours,
Yury V. Zaytsev