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
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 @@
- 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
Related PRs are:
http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/3553 (already closed)
I send a close request to those since this is the most promising one.
Marc Perisa wrote:
> Related PRs are:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/3553 (already closed)
The patch fixes the above two, but _not_ the following two:
(I haven't actually tested the latter, but deduced it from
the source that they won't be fixed.)
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)
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.
A commit in branch main references this bug:
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-`.
Reported by: email@example.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