Bug 914733

Summary: Do not fail hardly when 'compress' is unable to give sufficient compress ratio (was: Unable to create tar.Z achieves.)
Product: [Fedora] Fedora Reporter: Pavel Raiskup <praiskup>
Component: tarAssignee: Pavel Raiskup <praiskup>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: Frank.Buettner, kdudka, ovasik, praiskup
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 759371 Environment:
Last Closed: 2013-09-12 09:15:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 759371    
Bug Blocks:    
Attachments:
Description Flags
Warn only when this issue occurs. none

Description Pavel Raiskup 2013-02-22 16:20:54 UTC 
Hello,

the easiest way how to reproduce this issue (in case you have a little bit of
luck) issue is:

  $ dd if=/dev/urandom of=testfile bs=1K count=1024
  $ tar -cZf test.tar.Z testfile
  -rw-rw-r-- praiskup/praiskup 1048576 2013-02-22 16:49 testfile
  /home/praiskup/projects/tar/src/tar: Child returned status 2
  /home/praiskup/projects/tar/src/tar: Error is not recoverable: exiting now
  $ echo $?
  2

This is not _so_ big deal because tarball is successfully created anyway.  Just
the error return value is confusing for scripts / users.

As in is mentioned in $Summary, compress is unable to give to tar sufficient
compress ratio -> resulting "compressed" output is bigger then original data.
For that reason compress returns the exit value 2 (see man ncompress).

Because tar expects 0 return value from its child if the compression went OK,
it is confused by the value 2 and fails with confusing error message.

Expected behaviour:  Do not fail in such cases (possibly warn user by
appropriate message).

Pavel
Comment 1 Pavel Raiskup 2013-02-22 16:31:47 UTC 
Created attachment 701256 [details]
Warn only when this issue occurs.

Attaching possible solution for this issue.
Comment 2 Fedora End Of Life 2013-04-03 19:40:30 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 3 Pavel Raiskup 2013-09-12 09:15:11 UTC 
Per upstream discussion:

    http://www.mail-archive.com/bug-tar@gnu.org/msg03946.html

I am closing this bugreport WONTFIX.  If you feel there is possible to do
something with this issue, feel free to continue with comments.

-----

Because of tl;dr upstream thread, the main reason is that GNU gzip and
compress have bad APIs (yes, gzip has the same problem as compress) and if we
fixed tar for that upstream, (a) GNU gzip people would be held to not change
"broken" API and (b) non-GNU gzip implementation would result in failures by
default when used by GNU tar.

The reason why I think this is not worth to fix downstream is that it would be
quite complicated fix for very unlikely problem (e.g. we would have to
incorporate new non-upstream options - as simple program name comparison is
not good enough).  The result would be uncomfortable divergence against
upstream.

Pavel