nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brandon DeVries <>
Subject Re: behavior of posix vs gnu - Mac users and more
Date Tue, 03 Feb 2015 12:52:16 GMT
So, my knowledge comes entirely from the past 5 minutes of googling, but
from the gnu " Controlling the Archive Format" page [1] the options are
described as follows:

Format used by GNU tar versions up to 1.13.25. This format derived from an
early POSIX standard, adding some improvements such as sparse file handling
and incremental archives. Unfortunately these features were implemented in
a way incompatible with other archive formats.

Archives in `gnu' format are able to hold file names of unlimited length.

Archive format defined by POSIX.1-2001 specification. This is the most
flexible and feature-rich format. It does not impose any restrictions on
file sizes or file name lengths. This format is quite recent, so not all
tar implementations are able to handle it properly. However, this format is
designed in such a way that any tar implementation able to read `ustar'
archives will be able to read most `posix' archives as well, with the only
exception that any additional information (such as long file names etc.)
will in such case be extracted as plain text files along with the files it
refers to.

This archive format will be the default format for future versions of GNU

Aside from being more recent and thus not necessarily universally
supported, it sounds like posix is the the better choice going forward.



On Tue, Feb 3, 2015 at 7:29 AM, Joe Witt <> wrote:

> Hello
> We have a report of issues building on Mac in particular due to long file
> names.  Another dev has offered a patch which is solving it for them.
> What I am concerned about here is tradeoffs/portability of using posix vs
> gnu, etc..
> I've always found tar/portability issues maddening but that is largely due
> to my own ignorance.
> Does anyone understand this problem well enough to make a suggestion?  I am
> happy to apply this patch if it does indeed help Mac users but obviously
> don't want to create problems for anyone else in doing so.
> Thanks
> Joe

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message