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@xxxxxxx 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@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list