`borg import-tar` does not strip leading `./` from filenames, making mount access impossible

Have you checked borgbackup docs, FAQ, and open Github issues?

Yes

Is this a BUG / ISSUE report or a QUESTION?

Bug report

System information. For client/server mode post info for both machines.

Your borg version (borg -V).

borg 1.2.2 (not sure what version Hetzner uses as I can't execute the borg command directly on their storage box)

Operating system (distribution) and version.

Debian 11

Hardware / network configuration, and filesystems used.

Source is a .tar file, file system should be irrelevant. But just in case, the .tar file was created on ext4, the current system is running btrfs, and the backup was made to a ZFS remote.

How much data is handled by borg?

About 100 GB at most.

Full borg commandline that lead to the problem (leave away excludes and passwords)

borg import-tar --tar-filter='zstd -d' --progress --compression zstd ssh://XXX@XXX.your-storagebox.de:23/./backup/cadoth::2022-07-29 ~/Downloads/backup-20220729.tar.zst

sudo borg mount -v XXX@XXX.your-storagebox.de:23/./backup/cadoth /mnt/backup

Describe the problem you're observing.

When a tar archive was created as tar -cf NAME.tar . or similar (emphasis on the .), it leads to filenames starting with ./ in the archive. Borg does not strip this either on import-tar or mount by default, which results in it creating a second . directory, but that is "shadowed" by the regular "current directory" . entry, making it impossible to access. I even tried checkijng inode numbers but they seem to show up as identical.

root@cadoth /mnt/backup/2022-07-30 # ls -ail
total 0
4 drwxr-xr-x 1 root root 0 Oct 22 02:08 .
4 drwxr-xr-x 1 root root 0 Oct 22 02:08 .
1 drwxr-xr-x 1 root root 0 Oct 22 11:11 ..

Can you reproduce the problem? If so, describe how. If not, describe troubleshooting steps you took before opening the issue.

Yes, this is consistently reproducible with a tar archive created using the above syntax.

Looks like I can use borg mount --strip-components=1 to work around this, but the default behavior is still confusing and should be fixed.

Hmm, make_path_safe() already strips leading ../ but not ./.

[pgerber]

This doesn't appear to be a bug in the tar-importer as much as in the fuse implementation. I can reproduce this with borg create:

(Note that Borg 2 is used.)

user@dev-borg:~/src/borg$ borg create archive-47 .
user@dev-borg:~/src/borg$ borg list archive-47 | head -n 3
drwxr-xr-x user   root          0 Sat, 2022-10-29 17:44:07  .
drwxr-xr-x user   user          0 Sat, 2022-10-29 18:07:34  .git
drwxr-xr-x user   user          0 Sun, 2022-10-23 17:14:09  .git/branches

user@dev-borg:~/src/borg$ mkdir /tmp/b
user@dev-borg:~/src/borg$ borg mount /tmp/b

user@dev-borg:~/src/borg$ ls -lhd /tmp/b/archive-47
drwxr-xr-x 1 user user 0 Oct 29 18:17 /tmp/b/archive-47
user@dev-borg:~/src/borg$ ls -lh /tmp/b/archive-47 | head -n 3
total 144M
-rw-r--r-- 1 user user 1.2K Oct 23 17:16 AUTHORS
drwxr-xr-x 1 user user    0 Oct 23 17:19 build

user@dev-borg:~/src/borg$ ls -lha /tmp/b/archive-47 | head -n 3
total 144M
drwxr-xr-x 1 user user    0 Oct 29 18:17 .
drwxr-xr-x 1 user user    0 Oct 29 18:17 .

Also, note the incorrect group.

Hmm, I use . with borg create all the time and that doesn't trigger the issue, at least on v1.

[pgerber]

Okay, I think I'm starting to understand. There are two distinct issues here:

1. './' is kept during import-tar

   I believe I already have a fix for this that should make sure paths are stored in a normalized form (without './', '//' and such).

2. Fuse doesn't handle the archive item for '.' properly and insert a second '.' rather than setting metadata (e.g. the owner and group) on the existing directory.

[pgerber]

(The good news is my fix is already enough to see the directory content again even if there are still two '.'.)