-other purposes. As a result, @acronym{GNU} @command{tar} is
-incompatible with the current @sc{posix} spec, and with @command{tar}
-programs that follow it.
-
-We plan to reimplement these @acronym{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 @acronym{GNU} @command{tar} archive, which uses the
-@acronym{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.
-@acronym{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, @acronym{GNU} @command{tar} should be able to handle file
-names of practically unlimited length. So, if @acronym{GNU}
-@command{tar} fails to dump and retrieve files having more than 100
-characters, then there is a bug in @acronym{GNU} @command{tar},
-indeed.
-
-But, being strictly @sc{posix}, the limit was still 100 characters.
-For various other purposes, @acronym{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 @acronym{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 @acronym{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 @acronym{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.
-@acronym{GNU} @command{tar} should be able to produce and read true
-@sc{posix} format files, while being able to detect old @acronym{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
-@acronym{GNU} @command{tar} will go non-@sc{posix} again, or merely
-refuse to archive the file.
-
-There are plans so @acronym{GNU} @command{tar} support more fully the
-latest @sc{posix} format, while being able to read old V7 format,
-@acronym{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 @acronym{GNU}
-@command{tar} should disobey this specification, and automatically
-switch to using @acronym{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 @acronym{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 @acronym{GNU} @command{tar} should produce
-@sc{posix} format by default, whenever possible, producing archives
-older versions of @acronym{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 @acronym{GNU} @command{tar} to go closer to
-@sc{posix}. We can rush it. Another possibility is to produce the
-current @acronym{GNU} @command{tar} format by default for a few years,
-but have @acronym{GNU} @command{tar} versions from some 1.@var{POSIX}
-and up able to recognize all three formats, and let older
-@acronym{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) @acronym{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 @acronym{GNU} @command{tar} currently also store
-@code{atime} and @code{ctime}. If we want @acronym{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 @acronym{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 @acronym{GNU}-format archives, and recover its
-previous meaning from this fact.
-
-@acronym{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 @acronym{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
-@acronym{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 @acronym{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
-@acronym{GNU} mode. In a few years, when newer @acronym{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
-@acronym{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 @acronym{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 @acronym{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 @acronym{GNU} @command{tar} with @value{op-posix} and other
-@sc{posix} @command{tar}.
-
-In a few years, when @acronym{GNU} @command{tar} will produce
-@sc{posix} headers by default, @value{op-posix} will have a strong
-meaning and will disallow @acronym{GNU} extensions. But in the
-meantime, for a long while, @value{op-posix} in @acronym{GNU} tar will
-not disallow @acronym{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 @acronym{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.
-
-@acronym{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 @acronym{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 @acronym{GNU}
-@command{tar} has other @sc{posix} incompatibilities, and I need to
-segregate @acronym{GNU} @command{tar} semi-@sc{posix} archives from
-truly @sc{posix} archives, for @acronym{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.