I have here (in my opinion): - a bug in the documentation, - a regular bug, - an inconsistency, - two suggestions.
1) [2 bugs] According to the documentation, the --pax-option=KEY:=VALUE is expected to add the KEY=VALUE record at the 'beginning' of an extended header for each member. a) It seems that tar-1.32 (or tar-1.32.90) includes this record at the end. At first i thought it was simply wrong in the documentation. Then i found out that these keywords cannot be stored at the same time: - at the beginning, to fully mimic the KEY=VALUE found in an hypothetic global extended header - at the end, to override any global or file-specific extended header records In my opinion, to have them stored at the end is the right thing to do. Only the documentation should be amended, e.g. something like: 'KEYWORD:=VALUE' When used with one of archive-creation commands, these keyword/value pairs will be included as records at the end of an extended header for each file. This is effectively similar but not exactly equivalent to KEYWORD=VALUE form since it creates no global extended header records and these records can not be overriden by the other (file-specific) records at archive-reading. In fact, 'KEY=VALUE' would provide a default VALUE for KEY, while 'KEY:=VALUE' would force KEY to VALUE. b) Second, it seems that the KEY=VALUE pair is put in the extended header only if this header already exists. For example, with --pax-option=delete=ctime,delete=atime,KEY:=VALUE the KEY=VALUE record is currently not set for those files that have no nanoseconds in their mtime. 2) [inconsistency] In PAX format (and default options), you have two places where a file-specific mtime information is stored: in the regular mtime field, and in the extended header under the keyword "mtime". An archive-reading program may check these values against each other and warn if the integer part of the second one is not equal to the first one. But this is not possible for some members, that only have one value (the members with nanoseconds=0). Anyway, i would suggest to store the mtime record even if nanoseconds=0. 3) [suggestion 1] I suggest that --pax-options be a synonym of --pax-option, if possible. Indeed, this option usually contains more than one option (see several examples in the documentation). 4) [suggestion 2] (about checkpointing, not related to PAX format) See https://lists.gnu.org/archive/html/bug-tar/2016-03/msg00007.html Regards, Denis Excoffier.