Date: Sat, 03 Feb 2018 02:27:11 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 225639] FreeBSD's tar produces .tgz files that can not be read by other tar implementations (e.g windows 7-zip) Message-ID: <bug-225639-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225639 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-ml@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 bri= ngs up error messages and hangs. The reason can be found in tar's man page:=20 BUGS (...) All archive output is written in correctly-sized blocks, even if the o= ut- put is being compressed.(...)=20 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 padd= ing when decompressing an archive created by tar, although they still extr= act it correctly. Now this approach is outdated and needs to be fixed. This is not what GNU t= ar 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 dyi= ng) breed of tape drives any more, while just about everybody uses tar to shutt= le files back and forth between different platforms. Tar should do the right t= hing 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.=20 FreeBSD tar's behavior is unexpected and leads to errors. Yes, there are wa= ys to work around it, but people or code coming from Linux or Solaris environm= ents 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 c= an not just gloss over these and assume the user will somehow understand he can possibly work around them.=20 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-225639-8>