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@FreeBSD.org
Reporter: cwf...@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@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@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.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
