[SOLVED] Can't get rsync exclude to work correctly
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
This has been bothering me for a while, and I can't figure out where the problem is. I use ssh & rsync to do remote backups. On the machine I'm backing up, there is a "VirtualBox VMs" directory that is huge and doesn't need to be backed up. I also don't need to back up all the hidden directories in home. So, I run
the man rsync is a little confusing with its explanation of PATTERN
a section of it ( you should read the whole section, but it is confusing )
Quote:
if the pattern contains a / (not counting a trailing /) or a "**", then it is matched against the full pathname, including any
leading directories. If the pattern doesn’t contain a / or a "**", then it is matched only against the final component of the
filename. (Remember that the algorithm is applied recursively so "full filename" can actually be any portion of a path from the
starting directory on down.)
a trailing "dir_name/***" will match both the directory (as if "dir_name/" had been specified) and everything in the directory
(as if "dir_name/**" had been specified). This behaviour was added in version 2.6.7.
I would have to experiment with dir_name/*** and dir_name/** is see what the difference is, I'm not sure I understand what is in the manual fully
o if the pattern starts with a / then it is anchored to a particular spot in the hierarchy of files, otherwise it is matched
against the end of the pathname. This is similar to a leading ^ in regular expressions. Thus "/foo" would match a name of
"foo" at either the "root of the transfer" (for a global rule) or in the merge-file’s directory (for a per-directory rule). An
unqualified "foo" would match a name of "foo" anywhere in the tree because the algorithm is applied recursively from the top
down; it behaves as if each path component gets a turn at being the end of the filename. Even the unanchored "sub/foo" would
match at any point in the hierarchy where a "foo" was found within a directory named "sub". See the section on ANCHORING IN‐
CLUDE/EXCLUDE PATTERNS for a full discussion of how to specify a pattern that matches at the root of the transfer.
o if the pattern ends with a / then it will only match a directory, not a regular file, symlink, or device.
o rsync chooses between doing a simple string match and wildcard matching by checking if the pattern contains one of these three
wildcard characters: ’*’, ’?’, and ’[’ .
o a ’*’ matches any path component, but it stops at slashes.
o use ’**’ to match anything, including slashes.
o a ’?’ matches any character except a slash (/).
o a ’[’ introduces a character class, such as [a-z] or [[:alpha:]].
I wonder of that the OP is using is not working because rsync isn't handling the escaped space as expected. As I read the man page, their
Code:
--exclude="VirtualBox\ VMs/"
should work.
Perhaps the \ isn't needed, given the double quotes?
Indeed. For the shell, inside double quotes the backslash character retains its special meaning only when followed by one of five specific characters: $, `, ", \, or <newline>. The sequence "\ " is passed by the shell as a literal backslash character followed by a space.
Indeed. For the shell, inside double quotes the backslash character retains its special meaning only when followed by one of five specific characters: $, `, ", \, or <newline>. The sequence "\ " is passed by the shell as a literal backslash character followed by a space.
If I interpret this correctly, I should try without the backslash to escape the space:
Code:
--exclude="VirtualBox VMs/"
I'm relatively certain I tried that at one point, but I'll give it another shot tomorrow. I'm surprised this hasn't come up more often. Thanks for the help!
If I interpret this correctly, I should try without the backslash to escape the space:
Code:
--exclude="VirtualBox VMs/"
I'm relatively certain I tried that at one point, but I'll give it another shot tomorrow. I'm surprised this hasn't come up more often. Thanks for the help!
Please let us know whether or not that worked...
[nag]Again: Consider removing the space from the directory name entirely. OK. Won’t mention it again [\nag]
[SOLVED] Can't get rsync exclude to work correctly
This works as expected, with no escape character before the space:
Code:
--exclude={".*/","VirtualBox VMs/"}
I thought I tried that at one point, but I guess not. Truth be told, after using bash regularly 15 years, I still can't remember the rules for single and double quotes, escape characters, etc.
Quote:
Again: Consider removing the space from the directory name entirely.
100% agree. It's already gone. But I needed to figure out why this wasn't working, for the next time when I don't have the option to change the directory name. And for the next person out there that runs into this problem!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.