bugGNU tar - Bugs: bug #63048, chksum field explanation in GNU...


bug #63048: chksum field explanation in GNU tar manual is wrong

Submitter:  LGTR <lgtr>
Submitted:  Sun 11 Sep 2022 09:58:26 PM UTC
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment (Rich Markup)

Mon 12 Sep 2022 10:05:15 PM UTC, comment #1: 

I've seen that the manual says:
"When calculating the checksum, the chksum field is treated as if it were all blanks."

However the "blank" word has different meaning in different english jargons/slangs. I see for the author is means a space (0x20), however for other people blank means empty (0x00/NULL) or even zero (0x30/0) I think a little clarification should be added specifying the hex or decimal value for the chksum field.

LGTR <lgtr>
Sun 11 Sep 2022 09:58:26 PM UTC, original submission:  

GNU Tar 1.34 manual:

chksum explanation states that its value is the sum of all bytes in the header block.

That is incorrect. chksum is the is the sum of all bytes in the header block EXCEPT those in the 8 offsets for the chksum itself (offsets 148..155), with either:

1. Replacing each byte in chksum offset (148..155) by a space (20 hexadecimal, 30 decimal), before performing the sum, or
2. adding 256 decimal (100 hex) at the end in a single take.

LGTR <lgtr>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by lgtr (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.





    No changes have been made to this item

    Back to the top

    Powered by Savane 3.11