|
Bugzilla – Full Text Bug Listing |
| Summary: | bzip2 can't compress files on FAT{,32} filesystems | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Carl-Daniel Hailfinger <kernel01> |
| Component: | ConsoleApps | Assignee: | Ladislav Michnovic <lmichnovic> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Enhancement | ||
| Priority: | P3 - Medium | CC: | aj |
| Version: | Beta 4 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
<!-- 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. |
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.