René Scharfe <l....@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
