[Bug 225639] FreeBSD's tar produces .tgz files that can not be read by other tar implementations (e.g windows 7-zip)

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225639

            Bug ID: 225639
           Summary: FreeBSD's tar produces .tgz files that can not be read
                    by other tar implementations (e.g windows 7-zip)
           Product: Base System
           Version: 10.3-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: bin
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: cwf-ml at arcor.de

we have a number of script-based processes that, at some point, all do
something like

      tar -czf - /some/data | uuencode somedata.tgz | mailx -s "your data
somedata.tgz" windows.user at my.organization.example

These can not be used by users who run Outlook and 7zip or Winrar. 7zip brings
up error messages and hangs.

The reason can be found in tar's man page: 

BUGS
     (...)
     All archive output is written in correctly-sized blocks, even if the out-
     put is being compressed.(...) 
     For tar and cpio formats, the last block of output is padded to
     a full block size if the output is being written to standard output or to
     a character or block device such as a tape drive.  (...) Many com-
     pressors, including gzip(1) and bzip2(1), complain about the null padding
     when decompressing an archive created by tar, although they still extract
     it correctly.

Now this approach is outdated and needs to be fixed. This is not what GNU tar
does (the only other major Unix tar implementation that handles .tgz files),
nor is it the same as when we use

tar -cf - /some/data | gzip | uuencode somedata.tgz | mailx -s "your data
somedata.tgz" windows.user at my.organization.example

Frankly, hardly anbody uses tar to directly interface with the (rapidly dying)
breed of tape drives any more, while just about everybody uses tar to shuttle
files back and forth between different platforms. Tar should do the right thing
and produce standards compliant files as best as it can, and it should be
interchangeable with linux and other OS tars as far as commonly used options
are involved. 

FreeBSD tar's behavior is unexpected and leads to errors. Yes, there are ways
to work around it, but people or code coming from Linux or Solaris environments
do not expect or know this issue to exist at all. Furthermore, in target
architectures like Windows and use cases like data interchange with Windows
users, a target tool throwing errors is basically the same as failure; we can
not just gloss over these and assume the user will somehow understand he can
possibly work around them. 

Please change this tar behavior to reflect the one found in GNU tar. Create a
special option to force zero padding where required. Do not zero-pad after gz
encryption to stdout by default.

-- 
You are receiving this mail because:
You are the assignee for the bug.