Re: Sources for 3.18-rc1 not uploaded

[Junio C Hamano <gitster@pobox.com>]

René Scharfe <l.s.r@web.de> writes:

> That's by design -- extended headers are meant to be extracted as
> plain files by implementations that do not understand them.
>
> http://pubs.opengroup.org/onlinepubs/009695399/utilities/pax.html
> says: "If a particular implementation does not recognize the type, or
> the user does not have appropriate privilege to create that type, the
> file shall be extracted as if it were a regular file if the file type
> is defined to have a meaning for the size field that could cause data
> logical records to be written on the medium [...]."

Ahh, thanks for digging this up.  I knew POSIX said something about
this somewhere when I responded (and that is why I said "even though
I wouldn't have minded if the original implementation were to apply
the same umask for these entries that look like "dummy files" to
them."), but I didn't have patience to read it through myself.

> It's surprising and sad to see *pax* implementations not supporting
> pax extended headers in 2014, though.  It seems long file names
> etc. are not common enough.  Or perhaps pax is simply not used that
> much.

I would say that if we really want strictness, the _right_ way
forward might be:

 - Use tar.paxumask patch from Linus, to allow those who are aware
   of and care about the older pax implementations (i.e. Brian), to
   optionally tweak umasks applied to those extended header entries,
   while keeping the traditional behaviour as the default;

 - Warn that the default will change to use tar.paxumask that is the
   same as tar.umask in some future version of Git;

 - In some future version, flip the default.

Given that it will be a race between us flipping the default and the
affected implementations of extraction tools going extinct, however,
I do not think such a transition would be of high priority.