How to correctly extract a .tar.gz with md5.sum on solaris 10
Clash Royale CLAN TAG#URR8PPP
up vote
5
down vote
favorite
I am trying to extract a gcc-4.9.0.tar.gz downloaded from one of the gcc mirror site.
In order to check the md5 signature on it before I gunzip it I did
digest -a md5 -v gcc-4.9.0.tar.gz
which gave
md5 (gcc-4.9.0.tar.gz) = fe8786641134178ecfeee2dc7644a0d8
This matches with the md5.sum in the directory downloaded from the source.
Then I did
gzip -dc gcc-4.9.0.tar.gz | tar xvf -
The extraction began but soon terminated with a
tar: directory checksum error
I also tried to gunzip and untar separately like this
gunzip gcc-4.9.0.tar.gz
Then
tar -xvf gcc-4.9.0.tar
but it also ended with a checksum error.
Please How do I resolve this?
solaris tar gcc gzip
edited May 29 at 15:08
Jeff Schaller
31k846105
asked May 29 at 13:27
kplus
635
add a comment |Â
up vote
5
down vote
favorite
I am trying to extract a gcc-4.9.0.tar.gz downloaded from one of the gcc mirror site.
In order to check the md5 signature on it before I gunzip it I did
digest -a md5 -v gcc-4.9.0.tar.gz
which gave
md5 (gcc-4.9.0.tar.gz) = fe8786641134178ecfeee2dc7644a0d8
This matches with the md5.sum in the directory downloaded from the source.
Then I did
gzip -dc gcc-4.9.0.tar.gz | tar xvf -
The extraction began but soon terminated with a
tar: directory checksum error
I also tried to gunzip and untar separately like this
gunzip gcc-4.9.0.tar.gz
Then
tar -xvf gcc-4.9.0.tar
but it also ended with a checksum error.
Please How do I resolve this?
solaris tar gcc gzip
edited May 29 at 15:08
Jeff Schaller
31k846105
asked May 29 at 13:27
kplus
635
Did the filesystem fill up?
– Jeff Schaller
May 29 at 13:28
No I dont think so
– kplus
May 29 at 14:27
add a comment |Â
up vote
5
down vote
favorite
up vote
5
down vote
favorite
I am trying to extract a gcc-4.9.0.tar.gz downloaded from one of the gcc mirror site.
In order to check the md5 signature on it before I gunzip it I did
digest -a md5 -v gcc-4.9.0.tar.gz
which gave
md5 (gcc-4.9.0.tar.gz) = fe8786641134178ecfeee2dc7644a0d8
This matches with the md5.sum in the directory downloaded from the source.
Then I did
gzip -dc gcc-4.9.0.tar.gz | tar xvf -
The extraction began but soon terminated with a
tar: directory checksum error
I also tried to gunzip and untar separately like this
gunzip gcc-4.9.0.tar.gz
Then
tar -xvf gcc-4.9.0.tar
but it also ended with a checksum error.
Please How do I resolve this?
solaris tar gcc gzip
edited May 29 at 15:08
Jeff Schaller
31k846105
asked May 29 at 13:27
kplus
635
I am trying to extract a gcc-4.9.0.tar.gz downloaded from one of the gcc mirror site.
In order to check the md5 signature on it before I gunzip it I did
digest -a md5 -v gcc-4.9.0.tar.gz
which gave
md5 (gcc-4.9.0.tar.gz) = fe8786641134178ecfeee2dc7644a0d8
This matches with the md5.sum in the directory downloaded from the source.
Then I did
gzip -dc gcc-4.9.0.tar.gz | tar xvf -
The extraction began but soon terminated with a
tar: directory checksum error
I also tried to gunzip and untar separately like this
gunzip gcc-4.9.0.tar.gz
Then
tar -xvf gcc-4.9.0.tar
but it also ended with a checksum error.
Please How do I resolve this?
solaris tar gcc gzip
edited May 29 at 15:08
Jeff Schaller
31k846105
asked May 29 at 13:27
kplus
635
edited May 29 at 15:08
Jeff Schaller
31k846105
edited May 29 at 15:08
Jeff Schaller
31k846105
edited May 29 at 15:08
Jeff Schaller
31k846105
31k846105
asked May 29 at 13:27
kplus
635
asked May 29 at 13:27
kplus
635
asked May 29 at 13:27
kplus
635
635
Did the filesystem fill up?
– Jeff Schaller
May 29 at 13:28
No I dont think so
– kplus
May 29 at 14:27
add a comment |Â
Did the filesystem fill up?
– Jeff Schaller
May 29 at 13:28
No I dont think so
– kplus
May 29 at 14:27
Did the filesystem fill up?
– Jeff Schaller
May 29 at 13:28
Did the filesystem fill up?
– Jeff Schaller
May 29 at 13:28
No I dont think so
– kplus
May 29 at 14:27
No I dont think so
– kplus
May 29 at 14:27
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
5
down vote
accepted
You need to use gtar, it is usually preinstalled with package SUNWgtar:
gzip -dc gcc-4.9.0.tar.gz | /usr/sfw/bin/gtar -xf -
echo $?
0
Native Solaris unpatched tar may have problems with files created with GNU tar. See answer of @schily why.
answered May 29 at 13:51
Sasha Golikov
1317
This seems to have worked , but why the echo $?
– kplus
May 29 at 14:38
$?variable is return code of previous command (tar). 0 is success. Other return code is failure. You do not need to check it every time, this is optional.
– Sasha Golikov
May 29 at 14:50
1
Solaris tar does not have any limitation related to this problem. If GNU tar did work correctly, it did create an archive that could be unpacked by Solaris tar.
– schily
May 29 at 14:52
1
Please read my answer for a proof! I cannot say whether there is an updated tar binary for Solaris 10, but since there is a source modification from March 2010 (see my answer), there is a big chance for such an update.
– schily
May 29 at 15:17
Thank you! BTW: GNU tar is based on SUG-tar from the Sun employee John Gilmore and originally written in 1987 (star is from 1982). In 1987, the POSIX standard did not have the 100+255 naming extension. The algorithm for the 'L' extension in GNU tar is however from around 1989 written by GNU people.
– schily
May 29 at 15:59
add a comment |Â
up vote
7
down vote
It seems that the tar archive is defective or not standard compliant.
Note that I fetched the archive as bz2 image and had no problems with using bzip2 -d gcc-4.9.0.tar.bz2 < tar tvf -.
The unpacked archive has the md5 checksum: 6b8f599053a52e7c2076485d1ad3e747.
I am now fetching the .gz file, let's see what I get...
OK, here is the md5 checksum from gcc-4.9.0.tar.gz fe8786641134178ecfeee2dc7644a0d8 which is the same you see.
Note that your problem usually happens when the archive has been created by gtar, but in rare cases results in a directory checksum error.
If you like to better understand what's going on, I recommend you to use the tartestprogram that comes with star.
Fetch the latest schilytoolsfrom:
http://sourceforge.net/projects/schilytools/files/
compile and then run the program tartest/OBJ/*/tartest < gcc-4.9.0.tar.
I did this and discovered that the reason is that the archive uses a GNU vendor specific "file type" 'L' in a tar header.
IMPORTANT: if GNU tar was halfway standard compliant or at least halfway bug-free, this problem did not happen as the file name in question did perfectly fit into the POSIX.1-1988 100+255 name-scheme. So this is another hint on why people should avoid to use GNU tar at all.
I recommend to use star.
Every single feature in star is fully under control of a property description structure. If you specify an archive format, star will never create archive content that is related to a different archive format.
If you e.g. call:
star -c -f out.tar -Hustar somedir
star will use a 100% compliant POSIX.1-1988 archive format and in case that there is a file that would not fit into that archive format, star writes a warning instead of archiving the file using nonstandard methods.
BTW: Here is the changeset, where Sun added support for this vendor unique feature:
changeset: 11995:caff1bd711f5
user: Rich Burridge <rich.burridge@sun.com>
date: Thu Mar 25 13:21:39 2010 -0700
description:
6202362 Solaris tar can't unpack files created with GNU tar
modified:
usr/src/cmd/tar/tar.c
answered May 29 at 14:49
schily
8,63821435
The changeset shown for Sun tar went into Solaris 11, not Solaris 10, so doesn't help the original poster until they upgrade to a current OS release.
– alanc
May 31 at 0:59
Thanks Alan for checking! Since the tar source has some #ifdefs for older Solaris releases, it does not look really hard to do a backport. It of course was better if people did publish 100% POSIX compliant TAR archives for source packages.
– schily
May 31 at 7:53
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
accepted
You need to use gtar, it is usually preinstalled with package SUNWgtar:
gzip -dc gcc-4.9.0.tar.gz | /usr/sfw/bin/gtar -xf -
echo $?
0
Native Solaris unpatched tar may have problems with files created with GNU tar. See answer of @schily why.
answered May 29 at 13:51
Sasha Golikov
1317
This seems to have worked , but why the echo $?
– kplus
May 29 at 14:38
$?variable is return code of previous command (tar). 0 is success. Other return code is failure. You do not need to check it every time, this is optional.
– Sasha Golikov
May 29 at 14:50
1
Solaris tar does not have any limitation related to this problem. If GNU tar did work correctly, it did create an archive that could be unpacked by Solaris tar.
– schily
May 29 at 14:52
1
Please read my answer for a proof! I cannot say whether there is an updated tar binary for Solaris 10, but since there is a source modification from March 2010 (see my answer), there is a big chance for such an update.
– schily
May 29 at 15:17
Thank you! BTW: GNU tar is based on SUG-tar from the Sun employee John Gilmore and originally written in 1987 (star is from 1982). In 1987, the POSIX standard did not have the 100+255 naming extension. The algorithm for the 'L' extension in GNU tar is however from around 1989 written by GNU people.
– schily
May 29 at 15:59
add a comment |Â
up vote
5
down vote
accepted
You need to use gtar, it is usually preinstalled with package SUNWgtar:
gzip -dc gcc-4.9.0.tar.gz | /usr/sfw/bin/gtar -xf -
echo $?
0
Native Solaris unpatched tar may have problems with files created with GNU tar. See answer of @schily why.
answered May 29 at 13:51
Sasha Golikov
1317
This seems to have worked , but why the echo $?
– kplus
May 29 at 14:38
$?variable is return code of previous command (tar). 0 is success. Other return code is failure. You do not need to check it every time, this is optional.
– Sasha Golikov
May 29 at 14:50
1
Solaris tar does not have any limitation related to this problem. If GNU tar did work correctly, it did create an archive that could be unpacked by Solaris tar.
– schily
May 29 at 14:52
1
Please read my answer for a proof! I cannot say whether there is an updated tar binary for Solaris 10, but since there is a source modification from March 2010 (see my answer), there is a big chance for such an update.
– schily
May 29 at 15:17
Thank you! BTW: GNU tar is based on SUG-tar from the Sun employee John Gilmore and originally written in 1987 (star is from 1982). In 1987, the POSIX standard did not have the 100+255 naming extension. The algorithm for the 'L' extension in GNU tar is however from around 1989 written by GNU people.
– schily
May 29 at 15:59
add a comment |Â
up vote
5
down vote
accepted
up vote
5
down vote
accepted
You need to use gtar, it is usually preinstalled with package SUNWgtar:
gzip -dc gcc-4.9.0.tar.gz | /usr/sfw/bin/gtar -xf -
echo $?
0
Native Solaris unpatched tar may have problems with files created with GNU tar. See answer of @schily why.
answered May 29 at 13:51
Sasha Golikov
1317
You need to use gtar, it is usually preinstalled with package SUNWgtar:
gzip -dc gcc-4.9.0.tar.gz | /usr/sfw/bin/gtar -xf -
echo $?
0
Native Solaris unpatched tar may have problems with files created with GNU tar. See answer of @schily why.
answered May 29 at 13:51
Sasha Golikov
1317
edited May 29 at 15:41
answered May 29 at 13:51
Sasha Golikov
1317
answered May 29 at 13:51
Sasha Golikov
1317
answered May 29 at 13:51
Sasha Golikov
1317
1317
This seems to have worked , but why the echo $?
– kplus
May 29 at 14:38
$?variable is return code of previous command (tar). 0 is success. Other return code is failure. You do not need to check it every time, this is optional.
– Sasha Golikov
May 29 at 14:50
1
Solaris tar does not have any limitation related to this problem. If GNU tar did work correctly, it did create an archive that could be unpacked by Solaris tar.
– schily
May 29 at 14:52
1
Please read my answer for a proof! I cannot say whether there is an updated tar binary for Solaris 10, but since there is a source modification from March 2010 (see my answer), there is a big chance for such an update.
– schily
May 29 at 15:17
Thank you! BTW: GNU tar is based on SUG-tar from the Sun employee John Gilmore and originally written in 1987 (star is from 1982). In 1987, the POSIX standard did not have the 100+255 naming extension. The algorithm for the 'L' extension in GNU tar is however from around 1989 written by GNU people.
– schily
May 29 at 15:59
add a comment |Â
This seems to have worked , but why the echo $?
– kplus
May 29 at 14:38
$?variable is return code of previous command (tar). 0 is success. Other return code is failure. You do not need to check it every time, this is optional.
– Sasha Golikov
May 29 at 14:50
1
Solaris tar does not have any limitation related to this problem. If GNU tar did work correctly, it did create an archive that could be unpacked by Solaris tar.
– schily
May 29 at 14:52
1
Please read my answer for a proof! I cannot say whether there is an updated tar binary for Solaris 10, but since there is a source modification from March 2010 (see my answer), there is a big chance for such an update.
– schily
May 29 at 15:17
Thank you! BTW: GNU tar is based on SUG-tar from the Sun employee John Gilmore and originally written in 1987 (star is from 1982). In 1987, the POSIX standard did not have the 100+255 naming extension. The algorithm for the 'L' extension in GNU tar is however from around 1989 written by GNU people.
– schily
May 29 at 15:59
This seems to have worked , but why the echo $?
– kplus
May 29 at 14:38
This seems to have worked , but why the echo $?
– kplus
May 29 at 14:38
$? variable is return code of previous command (tar). 0 is success. Other return code is failure. You do not need to check it every time, this is optional.– Sasha Golikov
May 29 at 14:50
$? variable is return code of previous command (tar). 0 is success. Other return code is failure. You do not need to check it every time, this is optional.– Sasha Golikov
May 29 at 14:50
1
1
Solaris tar does not have any limitation related to this problem. If GNU tar did work correctly, it did create an archive that could be unpacked by Solaris tar.
– schily
May 29 at 14:52
Solaris tar does not have any limitation related to this problem. If GNU tar did work correctly, it did create an archive that could be unpacked by Solaris tar.
– schily
May 29 at 14:52
1
1
Please read my answer for a proof! I cannot say whether there is an updated tar binary for Solaris 10, but since there is a source modification from March 2010 (see my answer), there is a big chance for such an update.
– schily
May 29 at 15:17
Please read my answer for a proof! I cannot say whether there is an updated tar binary for Solaris 10, but since there is a source modification from March 2010 (see my answer), there is a big chance for such an update.
– schily
May 29 at 15:17
Thank you! BTW: GNU tar is based on SUG-tar from the Sun employee John Gilmore and originally written in 1987 (star is from 1982). In 1987, the POSIX standard did not have the 100+255 naming extension. The algorithm for the 'L' extension in GNU tar is however from around 1989 written by GNU people.
– schily
May 29 at 15:59
Thank you! BTW: GNU tar is based on SUG-tar from the Sun employee John Gilmore and originally written in 1987 (star is from 1982). In 1987, the POSIX standard did not have the 100+255 naming extension. The algorithm for the 'L' extension in GNU tar is however from around 1989 written by GNU people.
– schily
May 29 at 15:59
add a comment |Â
up vote
7
down vote
It seems that the tar archive is defective or not standard compliant.
Note that I fetched the archive as bz2 image and had no problems with using bzip2 -d gcc-4.9.0.tar.bz2 < tar tvf -.
The unpacked archive has the md5 checksum: 6b8f599053a52e7c2076485d1ad3e747.
I am now fetching the .gz file, let's see what I get...
OK, here is the md5 checksum from gcc-4.9.0.tar.gz fe8786641134178ecfeee2dc7644a0d8 which is the same you see.
Note that your problem usually happens when the archive has been created by gtar, but in rare cases results in a directory checksum error.
If you like to better understand what's going on, I recommend you to use the tartestprogram that comes with star.
Fetch the latest schilytoolsfrom:
http://sourceforge.net/projects/schilytools/files/
compile and then run the program tartest/OBJ/*/tartest < gcc-4.9.0.tar.
I did this and discovered that the reason is that the archive uses a GNU vendor specific "file type" 'L' in a tar header.
IMPORTANT: if GNU tar was halfway standard compliant or at least halfway bug-free, this problem did not happen as the file name in question did perfectly fit into the POSIX.1-1988 100+255 name-scheme. So this is another hint on why people should avoid to use GNU tar at all.
I recommend to use star.
Every single feature in star is fully under control of a property description structure. If you specify an archive format, star will never create archive content that is related to a different archive format.
If you e.g. call:
star -c -f out.tar -Hustar somedir
star will use a 100% compliant POSIX.1-1988 archive format and in case that there is a file that would not fit into that archive format, star writes a warning instead of archiving the file using nonstandard methods.
BTW: Here is the changeset, where Sun added support for this vendor unique feature:
changeset: 11995:caff1bd711f5
user: Rich Burridge <rich.burridge@sun.com>
date: Thu Mar 25 13:21:39 2010 -0700
description:
6202362 Solaris tar can't unpack files created with GNU tar
modified:
usr/src/cmd/tar/tar.c
answered May 29 at 14:49
schily
8,63821435
The changeset shown for Sun tar went into Solaris 11, not Solaris 10, so doesn't help the original poster until they upgrade to a current OS release.
– alanc
May 31 at 0:59
Thanks Alan for checking! Since the tar source has some #ifdefs for older Solaris releases, it does not look really hard to do a backport. It of course was better if people did publish 100% POSIX compliant TAR archives for source packages.
– schily
May 31 at 7:53
add a comment |Â
up vote
7
down vote
It seems that the tar archive is defective or not standard compliant.
Note that I fetched the archive as bz2 image and had no problems with using bzip2 -d gcc-4.9.0.tar.bz2 < tar tvf -.
The unpacked archive has the md5 checksum: 6b8f599053a52e7c2076485d1ad3e747.
I am now fetching the .gz file, let's see what I get...
OK, here is the md5 checksum from gcc-4.9.0.tar.gz fe8786641134178ecfeee2dc7644a0d8 which is the same you see.
Note that your problem usually happens when the archive has been created by gtar, but in rare cases results in a directory checksum error.
If you like to better understand what's going on, I recommend you to use the tartestprogram that comes with star.
Fetch the latest schilytoolsfrom:
http://sourceforge.net/projects/schilytools/files/
compile and then run the program tartest/OBJ/*/tartest < gcc-4.9.0.tar.
I did this and discovered that the reason is that the archive uses a GNU vendor specific "file type" 'L' in a tar header.
IMPORTANT: if GNU tar was halfway standard compliant or at least halfway bug-free, this problem did not happen as the file name in question did perfectly fit into the POSIX.1-1988 100+255 name-scheme. So this is another hint on why people should avoid to use GNU tar at all.
I recommend to use star.
Every single feature in star is fully under control of a property description structure. If you specify an archive format, star will never create archive content that is related to a different archive format.
If you e.g. call:
star -c -f out.tar -Hustar somedir
star will use a 100% compliant POSIX.1-1988 archive format and in case that there is a file that would not fit into that archive format, star writes a warning instead of archiving the file using nonstandard methods.
BTW: Here is the changeset, where Sun added support for this vendor unique feature:
changeset: 11995:caff1bd711f5
user: Rich Burridge <rich.burridge@sun.com>
date: Thu Mar 25 13:21:39 2010 -0700
description:
6202362 Solaris tar can't unpack files created with GNU tar
modified:
usr/src/cmd/tar/tar.c
answered May 29 at 14:49
schily
8,63821435
The changeset shown for Sun tar went into Solaris 11, not Solaris 10, so doesn't help the original poster until they upgrade to a current OS release.
– alanc
May 31 at 0:59
Thanks Alan for checking! Since the tar source has some #ifdefs for older Solaris releases, it does not look really hard to do a backport. It of course was better if people did publish 100% POSIX compliant TAR archives for source packages.
– schily
May 31 at 7:53
add a comment |Â
up vote
7
down vote
up vote
7
down vote
It seems that the tar archive is defective or not standard compliant.
Note that I fetched the archive as bz2 image and had no problems with using bzip2 -d gcc-4.9.0.tar.bz2 < tar tvf -.
The unpacked archive has the md5 checksum: 6b8f599053a52e7c2076485d1ad3e747.
I am now fetching the .gz file, let's see what I get...
OK, here is the md5 checksum from gcc-4.9.0.tar.gz fe8786641134178ecfeee2dc7644a0d8 which is the same you see.
Note that your problem usually happens when the archive has been created by gtar, but in rare cases results in a directory checksum error.
If you like to better understand what's going on, I recommend you to use the tartestprogram that comes with star.
Fetch the latest schilytoolsfrom:
http://sourceforge.net/projects/schilytools/files/
compile and then run the program tartest/OBJ/*/tartest < gcc-4.9.0.tar.
I did this and discovered that the reason is that the archive uses a GNU vendor specific "file type" 'L' in a tar header.
IMPORTANT: if GNU tar was halfway standard compliant or at least halfway bug-free, this problem did not happen as the file name in question did perfectly fit into the POSIX.1-1988 100+255 name-scheme. So this is another hint on why people should avoid to use GNU tar at all.
I recommend to use star.
Every single feature in star is fully under control of a property description structure. If you specify an archive format, star will never create archive content that is related to a different archive format.
If you e.g. call:
star -c -f out.tar -Hustar somedir
star will use a 100% compliant POSIX.1-1988 archive format and in case that there is a file that would not fit into that archive format, star writes a warning instead of archiving the file using nonstandard methods.
BTW: Here is the changeset, where Sun added support for this vendor unique feature:
changeset: 11995:caff1bd711f5
user: Rich Burridge <rich.burridge@sun.com>
date: Thu Mar 25 13:21:39 2010 -0700
description:
6202362 Solaris tar can't unpack files created with GNU tar
modified:
usr/src/cmd/tar/tar.c
answered May 29 at 14:49
schily
8,63821435
It seems that the tar archive is defective or not standard compliant.
Note that I fetched the archive as bz2 image and had no problems with using bzip2 -d gcc-4.9.0.tar.bz2 < tar tvf -.
The unpacked archive has the md5 checksum: 6b8f599053a52e7c2076485d1ad3e747.
I am now fetching the .gz file, let's see what I get...
OK, here is the md5 checksum from gcc-4.9.0.tar.gz fe8786641134178ecfeee2dc7644a0d8 which is the same you see.
Note that your problem usually happens when the archive has been created by gtar, but in rare cases results in a directory checksum error.
If you like to better understand what's going on, I recommend you to use the tartestprogram that comes with star.
Fetch the latest schilytoolsfrom:
http://sourceforge.net/projects/schilytools/files/
compile and then run the program tartest/OBJ/*/tartest < gcc-4.9.0.tar.
I did this and discovered that the reason is that the archive uses a GNU vendor specific "file type" 'L' in a tar header.
IMPORTANT: if GNU tar was halfway standard compliant or at least halfway bug-free, this problem did not happen as the file name in question did perfectly fit into the POSIX.1-1988 100+255 name-scheme. So this is another hint on why people should avoid to use GNU tar at all.
I recommend to use star.
Every single feature in star is fully under control of a property description structure. If you specify an archive format, star will never create archive content that is related to a different archive format.
If you e.g. call:
star -c -f out.tar -Hustar somedir
star will use a 100% compliant POSIX.1-1988 archive format and in case that there is a file that would not fit into that archive format, star writes a warning instead of archiving the file using nonstandard methods.
BTW: Here is the changeset, where Sun added support for this vendor unique feature:
changeset: 11995:caff1bd711f5
user: Rich Burridge <rich.burridge@sun.com>
date: Thu Mar 25 13:21:39 2010 -0700
description:
6202362 Solaris tar can't unpack files created with GNU tar
modified:
usr/src/cmd/tar/tar.c
answered May 29 at 14:49
schily
8,63821435
edited May 31 at 8:37
answered May 29 at 14:49
schily
8,63821435
answered May 29 at 14:49
schily
8,63821435
answered May 29 at 14:49
schily
8,63821435
8,63821435
The changeset shown for Sun tar went into Solaris 11, not Solaris 10, so doesn't help the original poster until they upgrade to a current OS release.
– alanc
May 31 at 0:59
Thanks Alan for checking! Since the tar source has some #ifdefs for older Solaris releases, it does not look really hard to do a backport. It of course was better if people did publish 100% POSIX compliant TAR archives for source packages.
– schily
May 31 at 7:53
add a comment |Â
The changeset shown for Sun tar went into Solaris 11, not Solaris 10, so doesn't help the original poster until they upgrade to a current OS release.
– alanc
May 31 at 0:59
Thanks Alan for checking! Since the tar source has some #ifdefs for older Solaris releases, it does not look really hard to do a backport. It of course was better if people did publish 100% POSIX compliant TAR archives for source packages.
– schily
May 31 at 7:53
The changeset shown for Sun tar went into Solaris 11, not Solaris 10, so doesn't help the original poster until they upgrade to a current OS release.
– alanc
May 31 at 0:59
The changeset shown for Sun tar went into Solaris 11, not Solaris 10, so doesn't help the original poster until they upgrade to a current OS release.
– alanc
May 31 at 0:59
Thanks Alan for checking! Since the tar source has some #ifdefs for older Solaris releases, it does not look really hard to do a backport. It of course was better if people did publish 100% POSIX compliant TAR archives for source packages.
– schily
May 31 at 7:53
Thanks Alan for checking! Since the tar source has some #ifdefs for older Solaris releases, it does not look really hard to do a backport. It of course was better if people did publish 100% POSIX compliant TAR archives for source packages.
– schily
May 31 at 7:53
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f446697%2fhow-to-correctly-extract-a-tar-gz-with-md5-sum-on-solaris-10%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Did the filesystem fill up?
– Jeff Schaller
May 29 at 13:28
No I dont think so
– kplus
May 29 at 14:27