archivemount reports wrong directory structure when subdir has the same name as its parent dir

[Silvan Schmitz]

Running Linux Mint 16 Cinnamon 64-bit

Test case:
==========
$ archivemount --version
archivemount version 0.8.1
FUSE library version: 2.9.2
fusermount version: 2.9.2
using FUSE kernel interface version 7.19
$ mkdir -p test/test mount
$ touch test/a test/test/b
$ tar -c test -f test.tar
$ archivemount test.tar mount
fuse: missing mountpoint parameter

Actual result:
==============
The file test/test/b is reported to be in test instead, but is accessible under neither path:
$ ls -R mount
mount:
test

mount/test:
ls: cannot access mount/test/b: No such file or directory
a b test

mount/test/test:
$ ls mount/test/b
ls: cannot access mount/test/b: No such file or directory
$ ls mount/test/test/b
ls: cannot access mount/test/test/b: No such file or directory

Expected result:
================
A file named b should be accessible under mount/test/test, like so:
$ ls -R mount
mount:
test

mount/test:
a test

mount/test/test:
b
$ ls mount/test/b
ls: cannot access mount/test/b: No such file or directory
$ ls mount/test/test/b
b

Reproducibility: Always

This behavior does not appear if test/test is instead named test/something_else.

The "fuse: missing mountpoint parameter" message seems to be always displayed if archivemount completes successfully, as a quick google search shows, so I guess it is an unrelated issue?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Grizzly (sven-witterstein)]

I have this on Mint Rebecca 64Bit (=Trusty, but with 3.16 / utopic kernel)

[Grizzly (sven-witterstein)]

I want to add that the gvfs mounting in Nautilus / Nemo works fine. But this is unpractical for it's long hashed pathname. I will try to build current archivemount from scratch and see what it does .

It funny, now this happens

sudo cd /mnt/archmount
sudo: cd: command not found

- wtf?

[Grizzly (sven-witterstein)]

There is a quite fresh 0.8.4 version out from 2015-02-27 - http://www.cybernoia.de/software/archivemount/
On that I observed the following behaviour:
- User can mount
- User is not allowed to unmount, only superuser
- When mounting as superuser, user cannot ls -l /mnt (instead of rights ??? are shown) properly

- in the mounted archive which contains an uncompressed tarball backup, beacause mksquashfs refused to create it, complaining about sockets, (ext2 boot + btrfs snaps of @root @home and partition / mbr dump like so:

dr-xr-xr-x 0 root root 0 Apr 7 19:24 boot
drwxr-xr-x 0 root root 0 Apr 9 10:01 home@2015-04-09_10:52:24
-rw-r--r-- 0 root root 1048576 Apr 7 21:20 mbr.bin
drwxr-xr-x 0 root root 0 Apr 9 10:01 opt@2015-04-09_10:52:24
dr-xr-xr-x 0 root root 0 Apr 9 10:50 root@2015-04-09_10:52:24
-rw-r--r-- 0 root root 478 Apr 7 21:22 sams.partedinfo
-rw-r--r-- 0 root root 17920 Apr 7 21:21 sda.sgdisk
lrwxrwxrwx 0 root root 0 Apr 7 21:18 snapme-btrfs.sh -> ../zz-snap/snapme-btrfs.sh

it is not possible to read all files. Mksquahsfs complains about cannot stat, mostly in the yumdb (it's a fedora backup)

The real problem is, it processes like one block each second from the mounted tar into the squahsfs, which is unacceptable.
So I will have to untar for now, even if I didnt't want to because I hoped to preserve permissions.

=> Updating archivemount should help in general, but is not the full solution yet to have the same functionality as transparent zip folders in redmonds proprietary os, sadly...

(gvfs refused to resync and to directly mksquashfs from it - so that was not a solution either...)

[Grizzly (sven-witterstein)]

Updated in LP to 0.8.5-1, now 0.8.7 is available

[kakurasan (kakurasan)]

I recently encountered similar problem with Office2013 installer image and reported the bug to the author, then the problem is fixed quickly (upstream 0.8.9 release). The testcase in this page also works as expected.