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?

Jeff Schaller
  • 66,199
  • 35
  • 114
  • 250
Kiteloopdesign
  • 79
  • 1
  • 9
  • 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. – Kiteloopdesign Mar 27 '18 at 21:55
  • 3
    @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 Answers1

2

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.

Rui F Ribeiro
  • 55,929
  • 26
  • 146
  • 227
L.Ray
  • 469
  • 2
  • 11