Public bug reported:
Mounting and adding contents inside mounted zip seems to work, but unmounting
results in a syslog error and changes are then not really written to the
archive as one would have expected them to be.
The error message on unmount is:
... fuse-zip[4923]: Error while closing archive: Operation not supported
... fuse-zip[4923]: File system unmounted
On Ubuntu 16.04.2 running the attached test script yields:
0|~/build/fuse-zip-test > bash fuse-zip-write-test.sh
Running fuse-zip write test
adding: test-file.txt (stored 0%)
Original archive contains:
Archive: test-archive.zip
Length DateTimeName
- -- -
5 2017-03-09 15:03 test-file.txt
- ---
5 1 file
Mount and copy file to archive
Now mount contains:
total 1
-rw-rw-r-- 1 bardino bardino 5 Mar 9 15:03 another-test-file.txt
-rw-rw-r-- 1 bardino bardino 5 Mar 9 15:03 test-file.txt
After unmounting archive contains:
Archive: test-archive.zip
Length DateTimeName
- -- -
5 2017-03-09 15:03 test-file.txt
- ---
5 1 file
Cleaning up
Where the zip is clearly missing the added another-test-file.txt after
the unmount.
Running the same script on e.g. a Debian Jessie host correctly results
in the files appearing in the zip after unmount. That system similarly
uses fuse-zip 0.4.0 but with an older libzip (libzip2 0.11.2-1.2) vs the
newer one in xenial (libzip4 1.0.1-0ubuntu1).
Apparently that difference causes the problem and it has been fixed in 0.4.2
upstream. Please refer to the details in the upstream bug #49 for details:
https://bitbucket.org/agalanin/fuse-zip/issues/49/is-it-broken-on-ubuntu-1604
I have verified that running apt-get build-dep fuse-zip and then
manually building fuse-zip 0.4.2 from upstream solves the problem on
Ubuntu 16.04.2, too.
Additional test system info:
0|~ > lsb_release -rd
Description:Ubuntu 16.04.2 LTS
Release:16.04
0|~ > apt-cache policy fuse-zip
fuse-zip:
Installed: 0.4.0-2build1
Candidate: 0.4.0-2build1
Version table:
*** 0.4.0-2build1 500
500 http://dk.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages
100 /var/lib/dpkg/status
** Affects: fuse-zip (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: "simple test script to illustrate the issue"
https://bugs.launchpad.net/bugs/1671527/+attachment/4834729/+files/fuse-zip-write-test.sh
** Description changed:
- Mounting and adding contents inside mounted zip seems to work, but unmounting
results in the syslog error and changes are then not really written to the
archive as one would have expected them to be.
+ Mounting and adding contents inside mounted zip seems to work, but unmounting
results in a syslog error and changes are then not really written to the
archive as one would have expected them to be.
The error message on unmount is:
... fuse-zip[4923]: Error while closing archive: Operation not supported
... fuse-zip[4923]: File system unmounted
-
On Ubuntu 16.04.2 running the attached test script yields:
0|~/build/fuse-zip-test > bash fuse-zip-write-test.sh
Running fuse-zip write test
- adding: test-file.txt (stored 0%)
+ adding: test-file.txt (stored 0%)
Original archive contains:
Archive: test-archive.zip
- Length DateTimeName
+ Length DateTimeName
- -- -
- 5 2017-03-09 15:03 test-file.txt
+ 5 2017-03-09 15:03 test-file.txt
- ---
- 5 1 file
+ 5 1 file
Mount and copy file to archive
Now mount contains:
total 1
-rw-rw-r-- 1 bardino bardino 5 Mar 9 15:03 another-test-file.txt
-rw-rw-r-- 1 bardino bardino 5 Mar 9 15:03 test-file.txt
After unmounting archive contains:
Archive: test-archive.zip
- Length DateTimeName
+ Length DateTimeName
- -- -
- 5 2017-03-09 15:03 test-file.txt
+ 5 2017-03-09 15:03 test-file.txt
- ---
- 5 1 file
+ 5 1 file
Cleaning up
Where the zip is clearly missing the added another-test-file.txt after
the unmount.
Running the same script on e.g. a Debian Jessie host correctly results
in the files appearing in the zip after unmount. That system similarly
uses fuse-zip 0.4.0 but with an older libzip (libzip2 0.11.2-1.2) vs the
- one newer one in xenial (libzip4 1.0.1-0ubuntu1).
+ newer one in xenial (libzip4 1.0.1-0ubuntu1).
Apparently that difference causes the problem and it has been fixed in 0.4.2
upstream. Please refer to the details in the upstream bug #49 for details:
