tar uses a variable of type "long" to store the amount of bytes written to the tape. This means that the -L option (--tape-length) will fail for tapes > 2 Gbyte on i386 machines. How-To-Repeat: Try the following two commands (for the sake of this example, /dev/null is used instead of a real tape, so you can try it immediately): tar -c -f /dev/null -L 2097151 /bin tar -c -f /dev/null -L 2097152 /bin The first one specifies a "tape" length which is just a tiny bit smaller than 2 Gbyte. It works fine. In the second command, the 32bit write counter overflows and leads to completely useless behaviour. After applying the fix below, both commands work fine. Tape sizes up to -- but not including -- 8 Ebytes (that is 8 million Tbytes) should work with this patch. :)
This problem is know with this version of tar. I updated the patch for buffer.c - but NOT tested it. There was no changes to tar.h as far as I can see on my system FreeBSD cerberus.home.sumirati.de 4.5-STABLE FreeBSD 4.5-STABLE #2: Mon Mar 18 12:35:37 CET 2002 --- buffer.c.orig Wed May 29 02:11:56 2002 +++ buffer.c.new Wed May 29 02:13:01 2002 @@ -746,7 +746,7 @@ { int err; int copy_back; - static long bytes_written = 0; + static off_t bytes_written = 0; if (f_checkpoint && !(++checkpoint % 10)) msg ("Write checkpoint %d\n", checkpoint); Another solution is to included a newer version of gnu tar as discussed in stable http://docs.freebsd.org/cgi/getmsg.cgi?fetch=423267+0+archive/2002/freebsd-stable/20020519.freebsd-stable Related PRs are: http://www.freebsd.org/cgi/query-pr.cgi?pr=3552 http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/3553 (already closed) http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/28820 http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/21208 I send a close request to those since this is the most promising one. Thanks Marc
Marc Perisa wrote: > [...] > Related PRs are: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3552 > http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/3553 (already closed) The patch fixes the above two, but _not_ the following two: > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/28820 > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/21208 (I haven't actually tested the latter, but deduced it from the source that they won't be fixed.) Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe)
State Changed From-To: open->patched Modern GNU tar which was just imported into the -CURRENT doesn't have this problem. Therefore, the problem will befilly resolved when tar upgrade is MFC'ed in about 1 month.
State Changed From-To: patched->closed duplicate pr.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/doc/commit/?id=be6e85b4a2a66e6bd5a0b0cd5c9e6d24ff5247fc commit be6e85b4a2a66e6bd5a0b0cd5c9e6d24ff5247fc Author: Fernando ApesteguÃa <fernape@FreeBSD.org> AuthorDate: 2021-04-18 17:22:23 +0000 Commit: Fernando ApesteguÃa <fernape@FreeBSD.org> CommitDate: 2021-04-20 09:42:36 +0000 [porters-handbook]: Clarify prefixes in patch file names Patches must start with `patch-` in order to be applied automatically. Conditional patches must not start with `patch-`. PR: 24903 Reported by: pauamma@gundo.com Approved by: 0mp (mentor) Differential Revision: https://reviews.freebsd.org/D28268 .../content/en/books/porters-handbook/slow-porting/_index.adoc | 4 ++++ 1 file changed, 4 insertions(+)
(In reply to commit-hook from comment #5) Bad reference in commit. It should have been 249038 and not 24903