On 10/27/2010 08:10 AM, Daniel P. Berrange wrote:
>> Use the newer and unlimited POSIX format instead.
>
> NACK. The whole point of using the v7 format is to be more portable to
> more systems. Rather, we should fix the filenames to be shorter; I'm on
> that.
What kind of systems don't support the newer POSIX formats ? Are there
actually any that are new enough for us to care about with libvirt ?
We're effectively only targetting OS that were released in the last
5 years, so either tar-pax or tar-ustar might be well enough supported
for our needs
Per the automake manual:
http://www.gnu.org/software/automake/manual/automake.html#Options
tar-v7 selects the old V7 tar format. This is the historical default.
This antiquated format is understood by all tar implementations and supports file names
with up to 99 characters. When given longer file names some tar implementations will
diagnose the problem while other will generate broken tarballs or use non-portable
extensions. Furthermore, the V7 format cannot store empty directories. When using this
format, consider using the filename-length-max=99 option to catch file names too long.
tar-ustar selects the ustar format defined by POSIX 1003.1-1988. This format is believed
to be old enough to be portable. It fully supports empty directories. It can store file
names with up to 256 characters, provided that the file name can be split at directory
separator in two parts, first of them being at most 155 bytes long. So, in most cases the
maximum file name length will be shorter than 256 characters. However you may run against
broken tar implementations that incorrectly handle file names longer than 99 characters
(please report them to bug-automake(a)gnu.org so we can document this accurately).
tar-pax selects the new pax interchange format defined by POSIX 1003.1-2001. It does not
limit the length of file names. However, this format is very young and should probably be
restricted to packages that target only very modern platforms. There are moves to change
the pax format in an upward-compatible way, so this option may refer to a more recent
version in the future.
tar-ustar might be acceptable, but tar-pax is too risky. But why even
worry about it, when it is trivial to avoid the problem in the first
place?
https://www.redhat.com/archives/libvir-list/2010-October/msg01078.html
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org