I have an iBasso DX50 digital music player and I have all of my music for it stored on a 128 GB micro SD card. I sync my music directory to it using the following command.
rsync -a --delete SRC DEST but I've noticed some odd behavior. I thought the --delete option would only delete files and directories in the destination that were not in the source but it did something a little strange, no it didn't remove anything from my source directory. I had two directories for the same album but one of them must have been slightly different and it only had one song in it. Then after syncing one day rsync must have deleted the directory with all the songs in it and left only the one that had only one song. How does --delete work that it would have this behavior and what can I do to fix it? Thanks.
--delete This tells rsync to delete extraneous files from the receiving side (ones that aren’t on the sending side), but only for the directories that are being synchronized. You must have asked rsync to send the whole directory (e.g. "dir" or "dir/") without using a wildcard for the directory’s contents (e.g. "dir/*") since the wildcard is expanded by the shell and rsync thus gets a request to transfer individual files, not the files’ parent directory. Files that are excluded from the transfer are also excluded from being deleted unless you use the --delete-excluded option or mark the rules as only matching on the sending side (see the include/exclude modifiers in the FILTER RULES section). Prior to rsync 2.6.7, this option would have no effect unless --recursive was enabled. Beginning with 2.6.7, deletions will also occur when --dirs (-d) is enabled, but only for directories whose contents are being copied. This option can be dangerous if used incorrectly! It is a very good idea to first try a run using the --dry-run option (-n) to see what files are going to be deleted. If the sending side detects any I/O errors, then the deletion of any files at the destination will be automatically disabled. This is to prevent temporary filesystem failures (such as NFS errors) on the sending side from causing a massive deletion of files on the destination. You can override this with the --ignore-errors option. The --delete option may be combined with one of the --delete-WHEN options without conflict, as well as --delete-excluded. However, if none of the --delete-WHEN options are specified, rsync will choose the --delete-during algorithm when talking to rsync 3.0.0 or newer, and the --delete-before algorithm when talking to an older rsync. See also --delete-delay and --delete-after.
To fix it, you might be able to use some recovery software to scan the device for the missing music files. It might be easier to redownload it from the store/re-rip it from the CD.
I haven't lost the files from my source DIR, it's all still there and all is still good. My issues are only in the destination DIR.
The set of options that I usually prefer for rsync is
rsync -va --delete (local transfer) or
rsync -vaz --delete (over network, "z" compresses the data to minimize the bandwidth needed).
But the thing that might have been the problem is that rsync can be a bit tricky in the way you specify the source and destination folders. You have to make sure they are written the same, down to the final slash character, i.e., like this:
rsync -vrt --delete /some/source/folder/ /some/dest/folder/
because it has happened in the past to me that a simple mistake like this:
rsync -vrt --delete /some/source/folder /some/dest/folder/
would result in ending up with a subfolder called "folder" in the destination folder (i.e.
/some/dest/folder/folder). It's just something to watch out for, rsync is just a bit quirky like that. And don't use globing.
Because --delete means that it will sync the dest directory to be exactly like the origin directory including deleting files and directories on the dest directory which exists there but not on the origin directory.