I have been doing some further testing with rsync, and I am not sure that the '--delete' switch is working. In making this assertion, I would like to make the following qualifications:
It is my understanding that the '--delete' switch is used to ensure that files that are deleted off the source are deleted from the target, so that the target remains a "mirror" of the source.
I've included the syntax of the command that I am using, in case it's the way I am specifying the argument that is the problem.
"c:\Program Files\cwRsync\rsync" -ari -vvv /cygdrive/d/Mail_Backup CJ2091::Test --stats --itemize-changes --checksum --no-whole-file --delete --partial --exclude-from="C:/zen/exclude.txt"
It should work. You may try --dry-run (-n) to see what rsync intends to do. Option --checksum can be quite slow. Try this:
"c:\Program Files\cwRsync\rsync" -a --dry-run -vvv /cygdrive/d/Mail_Backup CJ2091::Test --stats --itemize-changes --delete --exclude-from="C:/zen/exclude.txt"
OK, I will give that a go, thanks.
You're right about checksum, I have already decided to stop using it most of the time. Unfortunately I have some directories (and files) that are being updated by Offline Folders and the timestamp check for these files seeming to be triggering a complete re-sync.
I think I will either:
Create two sync processes, one for the Offline Folders where I have to use checksum and a separate process for the remaining files where I use timestamp (not my preferred option).
I have seen another option, where apparently the datestamp matching is more "relaxed". I am going to try this first, and hopefully it produces the desired results.
OK, I made the changes you suggested, ran the command and wrote the output to a text file (it's a big log file!)
The only entries I can see in the file are: 'send_files' and 'make_file'. I cannot see a single delete_file, and I checked the subdirectory where the files are located that ought to be deleted.
So it would appear that there is a problem. Any idea on how to isolate what might be causing this?
Maybe you can try to run dry-run command without exclude option, to check if all would-be-deleted files fall into to-be-excluded list.
Mystery solved. I have been testing cwRsync at 3 different sites. I started out with version 1.3 at all sites. v2 was released and I installed that at one site (the one where I have that 5GB file).
At this site (where I noticed that the issue with the --delete switch) I was running v1.3, I have upgraded to v2 and run a test on just the directory tree where the deleted files exist on the copy and it now works properly.
I'll run a full test on the data drive tonight and confirm that this is the case, but it looks likely that this function works correctly in v2.
Incidentally this site is also where I had the problem with the 1.6GB file, upgrading to v2 may address this issue as well.