1

I am using a bash wrapper script around rsync so I run with --dry-run option and then grep on it's output to check for "deleting", so I can make sure I am not losing data by some mistake. (I have not been able to find deleted files on the log output via --log-file but that's a separate question).

However, even if I am taking this extra safety step, I have still been able to mess up. I accidentally swapped the usual source and destination folders on the rsync command, and some files NOT present on destination folder where deleted from the source folder. I indeed saw the files being marked as deleted on the wrapper script output, but I missed the mistake because the path names are relative, and I assumed they were at the other (usually destination) end

I tried with --relative option to rsync as suggested in a similar question below, but it does not have the desired effect.

Absolute path in rsync dry-run statistics

(I am creating a new question as I do not have yet the reputation to comment on that one, and I do not think I should be asking on an answer, please correct me if I am wrong)

Any idea on how I can achieve this via some rsync command line option?

  • 1
    Instead of wrapping tools up in protective wrappers and possibly introducing the same bugs in the wrapper as you would otherwise do on the command line or in a script, just learn how the tools work. – Kusalananda Mar 26 '18 at 16:58
  • 1
    Not sure I understand what are you trying to say here. I have looked a lot into rsync documentation, and done quite a lot of experimenting. The reason for the wrapper is to avoid deleting files I do not want to delete, for which rsync doesn't seem to provide a solution. – Almendrico Mar 27 '18 at 21:55
  • 1
    @Kusalananda Even knowing how a tool works, people make mistakes, especially when tired or under pressure. Ways to prevent mistakes (or recover from them) are just as much a part of an admin's toolkit as are knowing how the tools work when no mistakes are made. – Wayne Conrad Aug 23 '19 at 20:22
  • @WayneConrad Absolutely. As is backing up important data, testing on a development system, working on copies of data before the possibly destructive command is issued on production data, for example. This is standard practice. – Kusalananda Aug 23 '19 at 20:30
1

I've made the same mistake, and searched for an answer to this question too. I haven't found a way to change rsync's basic behavior in the way you've described. I work around it by creating a unique file in the source folder before I do my dry-run. If I see that file show up in rsync's log marked for deletion, I know something's wrong.

| improve this answer | |
  • Makes sense, it's a hacky solution but it should work :) – Almendrico Mar 27 '18 at 21:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.