restic: restic should not read CACHEDIR.TAG in parent directories
Output of restic version
restic 0.9.6 compiled with go1.13.4 on linux/amd64 restic 0.9.6 (v0.9.6-200-g39f58a2b-dirty) compiled with go1.14.2 on linux/amd64
How did you run restic exactly?
/tmp/sample_dir% tree
.
├── CACHEDIR.TAG
└── src
└── backup_me.txt
/tmp/sample_dir% restic backup --exclude-caches $PWD/src
% restic ls latest
repository 22fc71ff opened successfully, password is correct
snapshot 3c6a0afd of [/tmp/sample_dir/src] filtered by [] at 2020-05-07 15:54:30.679914516 +0300 EEST):
/tmp
/tmp/sample_dir
What backend/server/service did you use to store the repository?
local/rest-server
Expected behavior
I think that tar behavior should be preserver here
/tmp/sample_dir% tar czvf test.tar.gz --exclude-caches $PWD/src
tar: Removing leading `/' from member names
/tmp/sample_dir/src/
/tmp/sample_dir/src/backup_me.txt
So if user explicitly asked to backup /tmp/sample_dir/src then restic should not look for CACHEDIR.TAG files in parent directories.
Actual behavior
restic doesn’t backup files if CACHEDIR.TAG is present in parent directory
Steps to reproduce the behavior
See above
Do you have any idea what may have caused this?
Do you have an idea how to solve the issue?
Did restic help you today? Did it make you happy in any way?
Excellent tool
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 2
- Comments: 22 (17 by maintainers)
I think the current behavior is a bug: If you move the
srcfolder from the sample dir into a new foldersrc0and then create a backup usingrestic backup --exclude-if-present CACHEDIR.TAG src0/src, then the content of the src folder is actually included in the backup.Only if you run
backup ~/.cache/*(and the CACHEDIR.TAG is in ~/cache). The point of this issue is to allow one to backup parts of a directory tree which contains a CACHEDIR.TAG in some parent folder, it restic is explicitly told to backup data within such a folder.So how about the ~/.cache directory? If this change would be implemented, I have to mark EVERY directory under ~/.cache with the CACHEDIR.TAG
And Brian Ford, the author of the proposal of CACHEDIR.TAG, wrote (I marked the relevant part):
Application Semantics
The presence of a cache directory tag within a given directory indicates that the entire contents of that directory, including any and all subdirectories underneath it, consists of cached information that can be re-generated if necessary from appropriate source material located elsewhere.
See: https://bford.info/cachedir/
So I vote for closing this feature request (not bug)
Thanks for reopening this!.
There is no inconsistency in ‘excluding’ part (actually reason of this bug). All tools except
resticdo exactly same thing.As about storing empty dir +
CACHEDIR.TAGitself, it’s a bit different. And I think thatresticis doing right thing here (same astar). It basically stores information that ‘directory was present, but just excluded from backup’. Ideallyresticshould also store information about direct exclude flags somewhere in snapshot, but it’s out of scope of this ticket.Again though; why don’t you just put your files that you want backed up in another directory than where you have the
CACHEDIR.TAGfile? It’s just one directory away.The problem is that the current behavior is what it is. If we change that, many many other users may see unexpected results. I don’t envision many users asking to back up specific dirs/files under a directory that has a
CACHEDIR.TAGfile, but we don’t know, and in particular your use case for this is quite specific.