Handling of relative paths inconsistent with restic

[paladincorners]

Describe the bug In autorestic, all relative paths are converted to their absolute paths prior to being passed to restic for backup. However, restic itself is able to handle relative paths (at least newer versions can).

When a relative path is passed to restic directly (without autorestic), although the snapshot "Paths" attribute (visible with restic snapshots) has the absolute path, the files inside each snapshot are stored as just the relative path (visible with restic ls latest).

However, if a relative path is passed to autorestic, the full absolute path is stored (restic ls latest).

Proposed solution: if a relative path is setup in the autorestic config file, pass the relative path, not absolute path, to restic.

Expected behavior Passing a relative path to autorestic should pass that relative path to restic, not resolve it to an absolute path.

Environment

• OS: Mac & Linux
• Version: 1.8.3

Additional context

[notDavid]

Hi there,

so my current backup method on macOS with restic is to:

1. create an apfs snapshot of the disk
2. mount this into ~/Volumes/restic_snapshot/
3. change the cwd to this snapshot folder with cd $HOME/Volumes/restic_snapshot
4. then create a backup with restic backup ./ which then saves the relative path (that is, it correctly omits the ~/Volumes/restic_snapshot/ part of the path.)

Do i understand correctly, there is no way (or workaround) to achieve this with autorestic currently?

[FedericoStra]

From https://autorestic.vercel.app/location#how-are-paths-resolved:

Paths can be absolute or relative. If relative they are resolved relative to the location of the config file. Tilde ~ paths are also supported for home folder resolution.

Resolving relative paths with respect to the location of the config file seems pretty cumbersome because it is usually buried inside ~/.config/autorestic/.autorestic.yml, so this behavior is pretty useless.

Suggestion

I think it would be nice to have a field base/cd/cwd/chdir/whatever inside locations that determines from where relative paths are resolved. For example,

locations:
  my-location-name:
    base: ~/projects # this determines the anchor for relative paths
    from:
      - path/to/backup
      - another/dir
      - /absolute/path
    to:
      - name-of-backend
      - also-backup-to-this-backend

would change directory to ~/projects and resolve path/to/backup and another from there, so that it traverses ~/projects/path/to/backup, ~/projects/another/dir and /absolute/path; the resulting snapshot should contain the paths

/path/to/backup
/path/to/backup/...
/another/dir
/another/dir/...
/absolute/path
/absolute/path/...

Addendum

There are already a lot of discussions about how restic should handle relative paths in its GitHub issues, for example https://github.com/restic/restic/issues/3131, https://github.com/restic/restic/issues/4762, https://github.com/restic/restic/issues/4026, and many others.

My suggestion would solve most of the use cases, while people over there keep fighting about the slashdot trick /./, tar's -C flag, --strip-prefix, --replace-prefix and other possibilities...

[Nubebuster]

When LLMs start hallucinating features of software from proposals in GitHub issues, that should indicate that an issue really needs to be fixed.

I've also had this with Prisma. It's feature incomplete and LLMs can do nothing but hallucinate to come up with solutions for your barely solvable problem.