So basically the arguments are: deleting files one by one: + Useful if you need to free up space on the origin as you go along
+ Useful if the link keeps dying and you can't complete a transfer in one go. - Adding a callback from the receiver to the sender to say that a file is complete is bad in terms of program flow and concurrency. deletion in batch: + Probably simpler to implement + There are already several phases of operation: scan, transfer, fix perms, ... + It's more conservative to make sure the transfer basically worked before deleting anything + Even if the link always dies, the directories will become more and more similar until eventually deletion is possible. + Gives you a chance to interrupt it if you realize during the transfer that you typed the wrong command. (Not very useful I know.) Any others? It might be a good idea to flush all the received files to the platter before deleting them, otherwise if you lose power on the receiver the files might be permanently lost. The patch must also be carefully checked for interactions with read_only and dry_run. People might be surprised if they modify a file between copying and deletion, but that's no worse than mv. I think carefully adding things like this gives a reasonable balance between simplicity and features. -- Martin