From owner-freebsd-bugs@freebsd.org Sat Feb 3 02:27:12 2018 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C722EDEC01 for ; Sat, 3 Feb 2018 02:27:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B9C96D2CD for ; Sat, 3 Feb 2018 02:27:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 7EE9D1FBA for ; Sat, 3 Feb 2018 02:27:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w132RBSe009997 for ; Sat, 3 Feb 2018 02:27:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w132RBBt009994 for freebsd-bugs@FreeBSD.org; Sat, 3 Feb 2018 02:27:11 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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) Date: Sat, 03 Feb 2018 02:27:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: cwf-ml@arcor.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 02:27:12 -0000 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.=