Rsync and .gvfs... Questions...
 

Something interesting about the way rsync works is it will push everything in the folder, including hidden directories. Okay fine, but .gvfs is hidden in the home directory which is where remote locations can be mounted.

Problem is, when .gvfs is taken up with rsync, it syncs that data too, even though it's essentially a duplicate. That means I could be copying the same data over again, albeit, in a slightly different location in the home directory.

AKA - home folder has contents, 1 2 3 4.

rsync -a /home/frank /media/externalhdd

Then external hdd would contain:

1 2 3 4
.gvfs/1 2 3 4

Of course, I can --exclude=.gvfs, but I'm wondering about something else. I noticed the man page had a -x flag for "do not leave file system." With gvfs being a virtual file system, would the -x flag take away the need for --exclude=.gvfs?

In other words:

rsync -ax /home/frank /media/externalhdd

Would that prevent .gvfs from traveling over rsync?

EDIT - The answer? No. I realized there was an rsync IRC chat and asked in there. One of the users said the -x flag cannot read enough of .gvfs to realize it's a separate file system, so it won't get flagged and excluded as such when the -x flag is used. Easiest thing is to just use the --exclude=.gvfs command. The only question I have now is, in 12.04 Beta that I have on my laptop, /home/user/.gvfs was moved to /home/user/.cache/gvfs, so I wonder if that will be a permanent move. Do any other distros do this by chance?

Normally the -x should work on any different filesystem. But, given the tricks that were used to do .gvfs, I can believe it might not be detected properly. Normally, once mounted, it should have a different filesystem index as seen in stat().

Also, if your rsync target already has .gvfs present, then --exclude=.gvfs might not be enough to block recursion. Try: --exclude=.gvfs{,'**'}

In some previous cases, I've even accidentally allowed .gvfs then later re-added it and it still resulted in the exclusion working properly the following time I used it. I don't see why it would somehow accidentally take it even if the exclude flag was present. These flags seem pretty robust, in my opinion. Once I read more about .gvfs I could understand how the -x flag didn't work, seeing as though .gvfs was designed to be a transparent as possible and all.

It can depend on whether it is detected as a directory, past or present, and previous copied as a directory. It can matter, for example, if it was mounted or not. This .gvfs stuff has been known to cause problems. Some programs abort when they get stat() errors from it.

Right, I understand that. I just don't understand how rsync could get confused about .gvfs if you're excluding .gvfs to begin with. I would think (and it's operated as such in my experience) as rather clean and clear... unless I'm misunderstanding what you meant about potentially needing --exclude=.gvfs{,'**'} ???

If it were a directory AND if the target already has a directory, then the --exclude for just the directory is moot. It has no effect. Files in that directory at the source do not match that --exclude pattern, and can be copied. The --exclude option does NOT mean to exclude a whole tree. It just adds a pattern to a list (the additions are in the order of the options) of patterns used to compare a filesystem object name to see if it should be transfered or not. If the target already has the object, this check is not even performed since it is moot. The pattern check for include and exclude is performed only if a transfer would otherwise need to be done ... for that ONE object.

The option: --exclude=foo{./'**'}
will expand to: --exclude=foo --exclude=foo/'**'
The directory foo will match the first, while all things in that directory will match the second.

If you used: --exclude=foo --include=foo/'**'
then the effective mean of that is "transfer the subtree if and only if the directory already exists at the target, but don't transfer the directory itself if it does not already exist at the target" (and hence the tree cannot then be transferred). It's actually a nice logic trick I've used before.

Of course the ".gvfs" case is messier because of filesystem issues in how this object is defined. It may be a directory sometimes (like if something is mounted there). If an rsync run had been made in the past without the --exclude, it could have copied that directory to the target. That could change how things get handled when only ONE --exclude is used. If later, it is a directory again, AND it has files in it, then those files would be copied even if --exclude=.gvfs is coded (because it doesn't need to copy the directory itself, so it would never run that name through the exclude pattern check).

I see what you're saying. But from actual experience, I've witnessed this exact scenario more than once:

Ran rsync without excluding .gvfs. When I saw the super long transfer, I realized .gvfs was in the mix. I canceled rsync and ran rsync again with .gvfs excluded. It ignored .gvfs on the 2nd pass, even though .gvfs already existed on the destination.

Considering I've consistently seen the exact same results from having .gvfs on the destination, then excluding it, and running it again and it still excludes fine, I just wonder what would have to happen for it to fumble....