I apply tar xvf mytarball.tar and when go deep into the new directory I can
see one file misses expected suffix.
The OS is Solaris 10.
When I unwrapped the tar with 7-zip on windows the relevant file was
ok.
Interestingly on Solaris 8 the same problem was with a different file
name.
Could someone suggest the possible cause?
Thank you.
--
rahed
Try using the E switch when making the tar file on Solaris. "E" is
documented in the
man pages. Once you make the tar file without E though you cant use E
to extract
after the fact if file names or sizes exceed the non E limits.
If the archive is made by another tar well you may have to use gtar or
star or
cpio or... whatever works
> Hello,
>
> I apply tar xvf mytarball.tar and when go deep into the new directory I can
> see one file misses expected suffix.
Thanks all for help.
--
Radek
>I apply tar xvf mytarball.tar and when go deep into the new directory I can
>see one file misses expected suffix.
>
>The OS is Solaris 10.
Did you create the archive with Solaris "tar"?
What is the path length of the file in question?
Note that Solaris "tar" does never silently truncate path names.
>When I unwrapped the tar with 7-zip on windows the relevant file was
>ok.
Why should this happen?
Solaris 10 tar is working correctly, so it is able to unpack what it did pack
before.
The old tar format is limited to a max path name length between 100 chars
and 256 chars. Any sane tar implementation warns you if there are files that
cannot be archived because of path length limitations.
Is it possible that you did create the achive with something that
calls itself "tar" but really is no TAR implementation (like e.g. GNU "tar")?
If you really need to archive filenames that cannot fit into a POSIX.1-1988
TAR archive, use star ftp://ftp.berlios.de/pub/star/alpha/ and use
star H=pax or star H=exustar, you then create POSIX.1-2001 compliant archives
that have no path length limitation (well, the limit is 8 billion chars ;-)
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
It is a really bad idea to recommend GNU tar because GNU tar by default
does not create tar archives but GNU pproprietary archives that
are incompatible to POSIX.
Sun tar by default has a limit of 256 chars for path names.
GNU tar creates non-POSIX-compliant archives in case that the path
name lenght is > 100 chars.
Do you really prefer a non-compliant archiver that causes problems
bacause of it's non-compliance?
>Try using the E switch when making the tar file on Solaris. "E" is
>documented in the
>man pages. Once you make the tar file without E though you cant use E
>to extract
>after the fact if file names or sizes exceed the non E limits.
The archives created by Sun tar -E may only be upacked by "Sun tar" and "star".
>If the archive is made by another tar well you may have to use gtar or
>star or
>cpio or... whatever works
gtar is not supporting all you may need and the tar part of the usual
"cpio" implementations is not really good.
> Did you create the archive with Solaris "tar"?
> What is the path length of the file in question?
>
> Note that Solaris "tar" does never silently truncate path names.
I did only tar xvf not cvf and exactly after gunzip on a cpan archive here:
If I remember correctly, a file Backend.pm missed .pm. Using GNU tar on
this archive worked without any issues.
--
Radek
You have been fooled by the creators of the archive :-(
This is _not_ a TAR archive, it is rather a GNU "tar" archive which is a
proprietary archive type that has some similarities with a real TAR archive.
As the longest Path name is 105 characters, you are hit by the incompatible
way of archiving long path names used with GNU "tar". This archive may only
unpacked correctly by GNU tar and by star, as star knows about GNU "tar".
You should make a bug report against the archive and send it to the creator
of the archive.