Precisions needed about --pax-option

[Denis Excoffier]

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.