No files mounted when tar uses relative paths

All the files appear to have been mounted within an unreachable ‘.’ folder, with the index file listing the them as being at locations like /./.config.

The tar.gz was generated on osx with a relative path given as well as a list of folders to exclude.

[Jamedjo]

Thanks!

I’d managed to get a hacky workaround but will retry with your patch.

The --recreate-index flag will come in handy and reminds me I was hoping for a “don’t recursively untar” option since this was a backup of my home directory including random tar files.

The fix I used was:

diff --git a/ratarmount.py b/ratarmount.py
old mode 100644
new mode 100755
index 89c4cd7..6d6cd83
--- a/ratarmount.py
+++ b/ratarmount.py
@@ -133,7 +133,7 @@ class IndexedTar:
                 indexedTar = IndexedTar( tarInfo.name, fileObject = fileObject, writeIndex = False )
                 fileObject.seek( fileObject.tell() ) # might be especially necessary if the .tar is not actually a tar!
 
-            path = "/" + tarInfo.name
+            path = "/" + re.sub(r"^\./", "", tarInfo.name)
 
             if indexedTar is not None and ( indexedTar.dirIndex or indexedTar.fileIndex ):
                 # actually apply the recursive tar mounting

[mxmlnkn]

The example.tar.gz is compressed. This is currently not supported. I added a warning message and avoided mounting an empty directory in case a compressed archive is specified. I was looking into combining ratarmount with lzopfs in order to add support for compressed archives but currently I don’t have the incentive as I don’t need it.

The problem with your TAR in comparison to my self created TARs with leading ./ is that it contains ./. I.e., output for tar tvf for my test TAR:

-rw-r--r-- user   4 2019-04-19 12:38 ./bar

your test TAR:

drwxr-xr-x user 0 2019-04-20 04:52 ./
-rw-r--r-- user 8 2019-04-20 04:52 ./file
drwxr-xr-x user 0 2019-04-20 04:52 ./somefolder/
-rw-r--r-- user 2 2019-04-20 04:52 ./somefolder/file

The problematic entry being the topmost one. It seems such a TAR can be created with:

tar --owner=user --group=group -cf ../foo.tar ./

Could you test the latest commit?