Bugzilla – Bug 55773
bzip2 can't compress files on FAT{,32} filesystems
Last modified: 2005-10-11 17:54:57 UTC
If bzip2 can't chmod its output file after compressing, it will delete the output file and bail out with an error. This makes bzip2 unusable on FAT{,32} filesystems. In contrast, gzip will show an error, but it will leave the output file intact.
<!-- SBZ_reproduce --> # cd /windows/C # echo foo >foo.txt # bzip2 -9 foo.txt bzip2: I/O or other error, bailing out. Possible reason follows. bzip2: Operation not permitted Input file = foo.txt, output file = foo.txt.bz2 bzip2: Deleting output file foo.txt.bz2, if it exists.
Any progress? I may need this bug fixed for Delta-RPMs which are currently under discussion in Bug 55783
I could add an option for keeping files if chmod or utime fails.
Could you make keeping files the default option? This way it would be consistent with gzip and less surprising to the user. Alternatively, could you move the chmod/utime checks to the beginning of the operation and output a meaningful error message? I had to strace bzip2 before I found out what happened. Currently it is very frustrating to compress files with bzip2 on a FAT filesystem because compression takes some time and after it is completely finished (just a last chmod/utime update needed), it decides to kill the compressed file.
It is no problem to code this. Unfortunately, I am not the author of bzip2, so that I do not want to change its features. Also our bzip2 would be different from the one from the other Linux distributions. Andreas what do you think?
Andreas? If we change this, we would be the only distribution where bzip2 on FAT{,32} filesystems does not fail. I think this would be a worthy feature.
tomas, can you prepare a patch and send to the bzip authors? Or discuss it with them before? If they like it, we should do it. And depending on the reasons for rejection, we might do it nevertheless - I leave this to you to judge.
bzip2 1.0.2 (tested with SuSE Linux 9.3) did not had this problem.
Björn: Did you test as root? This happens only if the drive was mounted by root and the test is done as normal user. I don't know whether this also happens with subfs.
Reassign it to new maintainer
In SL 10.0 it's O.K.
It works as root, and possibly as user if the user mounted it. But a local harddisk with a FAT partition is mounted on bootup and will not work as user. carldani@linux:/windows/D/Temp> mount|grep windows/D /dev/hda6 on /windows/D type vfat (rw,noexec,nosuid,nodev,gid=100,umask=0002,utf8=true) carldani@linux:/windows/D/Temp> ls carldani@linux:/windows/D/Temp> touch test carldani@linux:/windows/D/Temp> bzip2 test bzip2: I/O or other error, bailing out. Possible reason follows. bzip2: Operation not permitted Input file = test, output file = test.bz2 bzip2: Deleting output file test.bz2, if it exists. carldani@linux:/windows/D/Temp> ls test carldani@linux:/windows/D/Temp> cat /etc/SuSE-release SUSE LINUX 10.0 (i586) OSS VERSION = 10.0
Aha, I'm Sorry, I had root privilegs. From my point of view, it is not problem of bzip, but problem of mount. So at first, umask 0002 is not sufficient to have full acces to partition as nonroot user. Second, you should use mount with option "quiet" on FAT filesystem. Is it enough for you?
Are you satisfied? Can I close this bug?
If you want reopen this bug.