Comment 4 for bug 1313385

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...)