-@subsection @sc{gnu} @command{tar} and @sc{posix} @command{tar}
-
-@sc{gnu} @command{tar} was based on an early draft of the @sc{posix} 1003.1
-@code{ustar} standard. @sc{gnu} extensions to @command{tar}, such as the
-support for file names longer than 100 characters, use portions of the
-@command{tar} header record which were specified in that @sc{posix} draft as
-unused. Subsequent changes in @sc{posix} have allocated the same parts of
-the header record for other purposes. As a result, @sc{gnu} @command{tar} is
-incompatible with the current @sc{posix} spec, and with @command{tar} programs
-that follow it.
-
-We plan to reimplement these @sc{gnu} extensions in a new way which is
-upward compatible with the latest @sc{posix} @command{tar} format, but we
-don't know when this will be done.
-
-In the mean time, there is simply no telling what might happen if you
-read a @sc{gnu} @command{tar} archive, which uses the @sc{gnu} extensions, using
-some other @command{tar} program. So if you want to read the archive
-with another @command{tar} program, be sure to write it using the
-@samp{--old-archive} option (@samp{-o}).
-
-@FIXME{is there a way to tell which flavor of tar was used to write a
-particular archive before you try to read it?}
-
-Traditionally, old @command{tar}s have a limit of 100 characters. @sc{gnu}
-@command{tar} attempted two different approaches to overcome this limit,
-using and extending a format specified by a draft of some P1003.1.
-The first way was not that successful, and involved @file{@@MaNgLeD@@}
-file names, or such; while a second approach used @file{././@@LongLink}
-and other tricks, yielding better success. In theory, @sc{gnu} @command{tar}
-should be able to handle file names of practically unlimited length.
-So, if @sc{gnu} @command{tar} fails to dump and retrieve files having more
-than 100 characters, then there is a bug in @sc{gnu} @command{tar}, indeed.
-
-But, being strictly @sc{posix}, the limit was still 100 characters.
-For various other purposes, @sc{gnu} @command{tar} used areas left unassigned
-in the @sc{posix} draft. @sc{posix} later revised P1003.1 @code{ustar} format by
-assigning previously unused header fields, in such a way that the upper
-limit for file name length was raised to 256 characters. However, the
-actual @sc{posix} limit oscillates between 100 and 256, depending on the
-precise location of slashes in full file name (this is rather ugly).
-Since @sc{gnu} @command{tar} use the same fields for quite other purposes,
-it became incompatible with the latest @sc{posix} standards.
-
-For longer or non-fitting file names, we plan to use yet another set
-of @sc{gnu} extensions, but this time, complying with the provisions @sc{posix}
-offers for extending the format, rather than conflicting with it.
-Whenever an archive uses old @sc{gnu} @command{tar} extension format or @sc{posix}
-extensions, would it be for very long file names or other specialities,
-this archive becomes non-portable to other @command{tar} implementations.
-In fact, anything can happen. The most forgiving @command{tar}s will
-merely unpack the file using a wrong name, and maybe create another
-file named something like @file{@@LongName}, with the true file name
-in it. @command{tar}s not protecting themselves may segment violate!
-
-Compatibility concerns make all this thing more difficult, as we
-will have to support @emph{all} these things together, for a while.
-@sc{gnu} @command{tar} should be able to produce and read true @sc{posix} format
-files, while being able to detect old @sc{gnu} @command{tar} formats, besides
-old V7 format, and process them conveniently. It would take years
-before this whole area stabilizes@dots{}
-
-There are plans to raise this 100 limit to 256, and yet produce @sc{posix}
-conforming archives. Past 256, I do not know yet if @sc{gnu} @command{tar}
-will go non-@sc{posix} again, or merely refuse to archive the file.
-
-There are plans so @sc{gnu} @command{tar} support more fully the latest @sc{posix}
-format, while being able to read old V7 format, @sc{gnu} (semi-@sc{posix} plus
-extension), as well as full @sc{posix}. One may ask if there is part of
-the @sc{posix} format that we still cannot support. This simple question
-has a complex answer. Maybe that, on intimate look, some strong
-limitations will pop up, but until now, nothing sounds too difficult
-(but see below). I only have these few pages of @sc{posix} telling about
-``Extended tar Format'' (P1003.1-1990 -- section 10.1.1), and there are
-references to other parts of the standard I do not have, which should
-normally enforce limitations on stored file names (I suspect things
-like fixing what @kbd{/} and @kbd{@key{NUL}} means). There are also
-some points which the standard does not make clear, Existing practice
-will then drive what I should do.
-
-@sc{posix} mandates that, when a file name cannot fit within 100 to
-256 characters (the variance comes from the fact a @kbd{/} is
-ideally needed as the 156'th character), or a link name cannot
-fit within 100 characters, a warning should be issued and the file
-@emph{not} be stored. Unless some @value{op-posix} option is given
-(or @env{POSIXLY_CORRECT} is set), I suspect that @sc{gnu} @command{tar}
-should disobey this specification, and automatically switch to using
-@sc{gnu} extensions to overcome file name or link name length limitations.
-
-There is a problem, however, which I did not intimately studied yet.
-Given a truly @sc{posix} archive with names having more than 100 characters,
-I guess that @sc{gnu} @command{tar} up to 1.11.8 will process it as if it were an
-old V7 archive, and be fooled by some fields which are coded differently.
-So, the question is to decide if the next generation of @sc{gnu} @command{tar}
-should produce @sc{posix} format by default, whenever possible, producing
-archives older versions of @sc{gnu} @command{tar} might not be able to read
-correctly. I fear that we will have to suffer such a choice one of these
-days, if we want @sc{gnu} @command{tar} to go closer to @sc{posix}. We can rush it.
-Another possibility is to produce the current @sc{gnu} @command{tar} format
-by default for a few years, but have @sc{gnu} @command{tar} versions from some
-1.@var{POSIX} and up able to recognize all three formats, and let older
-@sc{gnu} @command{tar} fade out slowly. Then, we could switch to producing @sc{posix}
-format by default, with not much harm to those still having (very old at
-that time) @sc{gnu} @command{tar} versions prior to 1.@var{POSIX}.
-
-@sc{posix} format cannot represent very long names, volume headers,
-splitting of files in multi-volumes, sparse files, and incremental
-dumps; these would be all disallowed if @value{op-posix} or
-@env{POSIXLY_CORRECT}. Otherwise, if @command{tar} is given long
-names, or @samp{-[VMSgG]}, then it should automatically go non-@sc{posix}.
-I think this is easily granted without much discussion.
-
-Another point is that only @code{mtime} is stored in @sc{posix}
-archives, while @sc{gnu} @command{tar} currently also store @code{atime}
-and @code{ctime}. If we want @sc{gnu} @command{tar} to go closer to @sc{posix},
-my choice would be to drop @code{atime} and @code{ctime} support on
-average. On the other hand, I perceive that full dumps or incremental
-dumps need @code{atime} and @code{ctime} support, so for those special
-applications, @sc{posix} has to be avoided altogether.
-
-A few users requested that @value{op-sparse} be always active by
-default, I think that before replying to them, we have to decide
-if we want @sc{gnu} @command{tar} to go closer to @sc{posix} on average, while
-producing files. My choice would be to go closer to @sc{posix} in the
-long run. Besides possible double reading, I do not see any point
-of not trying to save files as sparse when creating archives which
-are neither @sc{posix} nor old-V7, so the actual @value{op-sparse} would
-become selected by default when producing such archives, whatever
-the reason is. So, @value{op-sparse} alone might be redefined to force
-@sc{gnu}-format archives, and recover its previous meaning from this fact.
-
-@sc{gnu}-format as it exists now can easily fool other @sc{posix} @command{tar},
-as it uses fields which @sc{posix} considers to be part of the file name
-prefix. I wonder if it would not be a good idea, in the long run,
-to try changing @sc{gnu}-format so any added field (like @code{ctime},
-@code{atime}, file offset in subsequent volumes, or sparse file
-descriptions) be wholly and always pushed into an extension block,
-instead of using space in the @sc{posix} header block. I could manage
-to do that portably between future @sc{gnu} @command{tar}s. So other @sc{posix}
-@command{tar}s might be at least able to provide kind of correct listings
-for the archives produced by @sc{gnu} @command{tar}, if not able to process
-them otherwise.
-
-Using these projected extensions might induce older @command{tar}s to fail.
-We would use the same approach as for @sc{posix}. I'll put out a @command{tar}
-capable of reading @sc{posix}ier, yet extended archives, but will not produce
-this format by default, in @sc{gnu} mode. In a few years, when newer @sc{gnu}
-@command{tar}s will have flooded out @command{tar} 1.11.X and previous, we
-could switch to producing @sc{posix}ier extended archives, with no real harm
-to users, as almost all existing @sc{gnu} @command{tar}s will be ready to read
-@sc{posix}ier format. In fact, I'll do both changes at the same time, in a
-few years, and just prepare @command{tar} for both changes, without effecting
-them, from 1.@var{POSIX}. (Both changes: 1---using @sc{posix} convention for
-getting over 100 characters; 2---avoiding mangling @sc{posix} headers for @sc{gnu}
-extensions, using only @sc{posix} mandated extension techniques).
-
-So, a future @command{tar} will have a @value{op-posix}
-flag forcing the usage of truly @sc{posix} headers, and so, producing
-archives previous @sc{gnu} @command{tar} will not be able to read.
-So, @emph{once} pretest will announce that feature, it would be
-particularly useful that users test how exchangeable will be archives
-between @sc{gnu} @command{tar} with @value{op-posix} and other @sc{posix} @command{tar}.
-
-In a few years, when @sc{gnu} @command{tar} will produce @sc{posix} headers by
-default, @value{op-posix} will have a strong meaning and will disallow
-@sc{gnu} extensions. But in the meantime, for a long while, @value{op-posix}
-in @sc{gnu} tar will not disallow @sc{gnu} extensions like @value{op-label},
-@value{op-multi-volume}, @value{op-sparse}, or very long file or link names.
-However, @value{op-posix} with @sc{gnu} extensions will use @sc{posix}
-headers with reserved-for-users extensions to headers, and I will be
-curious to know how well or bad @sc{posix} @command{tar}s will react to these.
-
-@sc{gnu} @command{tar} prior to 1.@var{POSIX}, and after 1.@var{POSIX} without
-@value{op-posix}, generates and checks @samp{ustar@w{ }@w{ }}, with two
-suffixed spaces. This is sufficient for older @sc{gnu} @command{tar} not to
-recognize @sc{posix} archives, and consequently, wrongly decide those archives
-are in old V7 format. It is a useful bug for me, because @sc{gnu} @command{tar}
-has other @sc{posix} incompatibilities, and I need to segregate @sc{gnu} @command{tar}
-semi-@sc{posix} archives from truly @sc{posix} archives, for @sc{gnu} @command{tar} should
-be somewhat compatible with itself, while migrating closer to latest
-@sc{posix} standards. So, I'll be very careful about how and when I will do
-the correction.