Storing absolute paths or relative paths?

Getting Help
1

Hi,

As shown in the examples below, restic seem to store the absolute path (c:\R1, when doing ‘ls’). But if you
cd to the folder (c:\R3), then it only stores for the snapshot (doing ‘snapshots’)

What is the meaning of having the full path on the snapshots?

Do I have to go do cd to the folder if I don’t want absolute path? (i.e. there is not an option like ‘–root-path c:\TOBK’)

c:>restic -r c:\R1 backup c:\TOBK
enter password for repository:
repository 81ae5660 opened (version 2, compression level auto)
created new cache in C:\Users\jalcaide\AppData\Local\restic
found 3 old cache directories in C:\Users\jalcaide\AppData\Local\restic, run restic cache --cleanup to remove them
no parent snapshot found, will read all files
[0:00] 0 index files loaded

Files: 5 new, 0 changed, 0 unmodified
Dirs: 4 new, 0 changed, 0 unmodified
Added to the repository: 91.322 MiB (89.589 MiB stored)

processed 5 files, 91.313 MiB in 0:03
snapshot b079617d saved

c:>

c:\TOBK>restic -r c:\R1 ls latest
enter password for repository:
repository 81ae5660 opened (version 2, compression level auto)
found 3 old cache directories in C:\Users\jalcaide\AppData\Local\restic, run restic cache --cleanup to remove them
[0:00] 100.00% 1 / 1 index files loaded
snapshot b079617d of [c:\TOBK] at 2025-12-13 01:06:01.7848264 +0100 CET by CISCO\jalcaide@CSCO-W-PW0JCGJ7 filtered by :
/c
/c/TOBK
/c/TOBK/20240908_011833.mp4
/c/TOBK/PICS
/c/TOBK/PICS/20240908_021559.jpg
/c/TOBK/SUBFOLDER
/c/TOBK/SUBFOLDER/x1.txt
/c/TOBK/x1.txt
/c/TOBK/x2.txt

c:\TOBK>restic -r c:\R1 snapshots
enter password for repository:
repository 81ae5660 opened (version 2, compression level auto)
found 3 old cache directories in C:\Users\jalcaide\AppData\Local\restic, run restic cache --cleanup to remove them
ID Time Host Tags Paths Size

b079617d 2025-12-13 01:06:01 CSCO-W-PW0JCGJ7 c:\TOBK 91.313 MiB

1 snapshots

c:\TOBK>

c:\TOBK>restic -r c:\R3 backup .
enter password for repository:
repository 6bc754b7 opened (version 2, compression level auto)
created new cache in C:\Users\jalcaide\AppData\Local\restic
found 3 old cache directories in C:\Users\jalcaide\AppData\Local\restic, run restic cache --cleanup to remove them
no parent snapshot found, will read all files
[0:00] 0 index files loaded

Files: 5 new, 0 changed, 0 unmodified
Dirs: 2 new, 0 changed, 0 unmodified
Added to the repository: 91.322 MiB (89.589 MiB stored)

processed 5 files, 91.313 MiB in 0:02
snapshot 918af900 saved

c:\TOBK>

c:\TOBK>restic -r c:\R3 ls latest
enter password for repository:
repository 6bc754b7 opened (version 2, compression level auto)
found 3 old cache directories in C:\Users\jalcaide\AppData\Local\restic, run restic cache --cleanup to remove them
[0:00] 100.00% 1 / 1 index files loaded
snapshot 918af900 of [c:\TOBK] at 2025-12-13 01:20:24.4270613 +0100 CET by CISCO\jalcaide@CSCO-W-PW0JCGJ7 filtered by :
/20240908_011833.mp4
/PICS
/PICS/20240908_021559.jpg
/SUBFOLDER
/SUBFOLDER/x1.txt
/x1.txt
/x2.txt

c:\TOBK>restic -r c:\R3 snapshots
enter password for repository:
repository 6bc754b7 opened (version 2, compression level auto)
found 3 old cache directories in C:\Users\jalcaide\AppData\Local\restic, run restic cache --cleanup to remove them
ID Time Host Tags Paths Size

918af900 2025-12-13 01:20:24 CSCO-W-PW0JCGJ7 c:\TOBK 91.313 MiB

1 snapshots

c:\TOBK>

2

Hi @resticint001

It seems restic always stores an absolute path in the path field of the snapshot file while it correctly stores relative paths in the snapshot tree.

I agree this is inconsistent; I assume it can’t be changed due to backward-compatibility-issues.

3

I went down this rabbit hole recently, and I think what you might be looking for is the –strip-prefix option that’s on the roadmap for Restic 0.19. More details are available in the Github discussion thread.

4 Likes
4

Thanks for the feature.

There is still one Q unanswered. Even if I cd to the directory (and I guess perhaps after the -strip-prefix option), I see information about the actual absolute path backed up. What is the significance of it? Can I get rid of it?

From outputs above:

5

The real reason is that the parent detection can’t work without that the absolute path. Just assume that you run restic backup . in /home/user/Documents and /home/user/Pictures. For a fast backup restic needs to tell those folders apart. That won’t work if the snapshots metadata just includes . as path.

Unless we have an alternate way of specifying backup sets (part of the discussions around --strip-prefix), that won’t change.

1 Like
6

This sounds to me like a lame excuse :wink:

Of course, you are right about parent detection. But there are also cases with absolute paths where parent detection fails (like where the same data is mounted under different mountpoints). And on the other hand, adding the possibility to consequently use relative paths does not break any parent detection for people choosing to use absolute paths.

Moreover, it is restic’s current implementation when running restic relative/path which does break parent usage: If you run /home/users$ restic backup Documents followed by /home$ restic backup users/Documents, you see that the second command does use the snapshot created by the first command as parent. However, it is not able to use it due to the different paths stored in the snapshot tree - as restic saves an absolute path in the snapshot file, but uses the relative path for the tree structure, which is inconsistent… (note that using correct relative paths in the snapshot file, this example would also not be able to detect the parent correctly; this is however intentional)

I agree that using dots in paths is difficult; FWIW, here is how rustic is doing it:

  • first paths are sanitized to remove dots where possible, e.g. ./user/ → user/ or path/to/../user → path/user
  • paths still containing dots are transformed into absolute paths; the tree in the snapshot exactly reflects that absolute path, i.e. /home/test$ rustic backup . and rustic backup /home/test produce identical snapshots and trees (and can use be used as parents for each other).
  • relative paths without dots are stored as relative paths in the snapshot description and the tree also represents that path →/mnt/a$ rustic backup test and /mnt/b$ rustic backup test do use each other as parent
7

I’m not sure why you’ve decided to mistake an explanation of the current status quo for an argument why this can’t be improved.

That’s just what I’ve said? As there are several suggestions floating around I’d like to take a look at those first before blindly deciding for a variant that can’t be changed anymore without breaking backwards compatibility.

True, but hardly surprising given the overall brittleness of the current behavior.

How many more links do you want to plaster all over the restic forum?

1 Like
8

Hey @MichaelEischer, you seem to be offended by my answer.I am very sorry about that, as this was not my intended at all. I wanted to help by stating the current behavior and show possible solutions/improvements.

Thanks for clarifying! I actually really misunderstood your answer as “this is not a topic about backwards compatibility, but instead a topic about parent detection”.

2 Likes
9

I wasn’t really aware of the approach to just store relative paths directly in the snapshot, so thanks for that.

Although, this would also amount to a somewhat breaking change when used in restic. Right now, some commands convert paths to absolute paths before looking up snapshots. For example restic snapshots --path . would return snapshots that contain the absolute snapshot path. But I’m ready to accept a certain amount of breakage for this particular behavior as the current path normalization sometimes results in very weird behavior.

2 Likes
10

Ah, that’s good to know - I wasn’t aware of this. Paths given to the filter snapshots via –path could actually be handled identically as I suggested to do in backup: Try to “dedot” by sanitizing paths; if still containing dots, convert to a absolute paths; if not, use the relative path. That would not even change anything in the case of using . . For actual relative paths, however, this would change the behavior (but IMO consistently).