Strange exclude behaviour

Hi guys,

so I’m running restic backup with some --exclude parameters and have noticed some strange behaviour as follows.
Say I am running

restic backup /home/test/Documents/a/b/c --exclude=/home/**/Documents
where /home/test/Documents/a/b/c contains some subfolders which contain various files, then the result will be that the snapshot will contain the directory structure up to /home/test/Documents/a/b but nothing more.
I understand that in this case the interaction between the folder which is specified to be backed up and the exclusion is somewhat contradictory, but I would not expect the snapshot to contain what it contains. It think that either of the two, the folder to be backed up, or the exclusion should take precedence. I think it would make most sense to let the folder to be backed up take precedence and let the exclusion in this case only apply to folders under the specified folder to be backed up (i.e. no folder named Documents anywhere in the hierarchy beneath /home/test/Documents/a/b/c should be included.

What do you guys think?

I don’t have time to test what you report now, but can you verify that the same thing happens when you order the arguments correctly? restic help backup tells us restic backup [flags] FILE/DIR [FILE/DIR] ... so your command should be restic backup --exclude=/home/**/Documents /home/test/Documents/a/b/c.

Hmm, thanks for pointing that out @rawtaz , I hadn’t even considered that the order mattered as I have had no problems at all with running the restic backup command with the following ordering:
restic backup FILE/DIR [FILE/DIR] ... [flags]

In any case, I tested the command with the preferred ordering and the result is the same…

This sounds like an instance of or to me. The exclude filters can in some cases also apply to paths outside the backup source directories.

Thank you @MichaelEischer, it seems possible that this is related yes. Are there any plans to change this behaviour?

I haven’t given the matter much thought so far, and at least for me it’s not a priority. Changing the behavior would require quite some thoughts about possible corner cases and how to handle those. Otherwise we could end up trading some unexpected behavior for some different unexpected behavior.

Yeah, I understand, bit of a tricky one… :thinking: