[opensuse-factory] pax is not tar
In 13.1M4, I did tar -cvf /mnt/usb/stuff.tar file1.ts file2.ts file3.ts On /mnt/usb was a NTFS formatted USB stick. The object of tarring was to preserve all native file attributes while transversing the foreign formatted media. After ejecting, I put it into a USB port on a Linux STB running busybox v1.0. After it automounted, I changed to the desired destination for extraction, and then tar -xvf <mountpoint>/stuff.tar . That gave me $SUBJECT. Apparently busybox tar isn't very smart. I've done this before successfully, making me believe something about tar in 13.1 is different. Is it? Is it a bug? Since I'm dealing with huge media files, experimenting is a lengthy process. I can't tell from the 13.1 tar man page what option might make busybox tar able to extract from a 13.1 tar file. Anyone know what's going on here? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 18.08.2013 08:18, schrieb Felix Miata:
In 13.1M4, I did
tar -cvf /mnt/usb/stuff.tar file1.ts file2.ts file3.ts
On /mnt/usb was a NTFS formatted USB stick. The object of tarring was to preserve all native file attributes while transversing the foreign formatted media. After ejecting, I put it into a USB port on a Linux STB running busybox v1.0. After it automounted, I changed to the desired destination for extraction, and then
tar -xvf <mountpoint>/stuff.tar .
That gave me $SUBJECT. Apparently busybox tar isn't very smart.
It is. But busybox 1.0 is almost 10 years old. And even with current busybox you need to enable the correct options.
I've done this before successfully, making me believe something about tar in 13.1 is different. Is it? Is it a bug?
No, it's a feature. The defaults changed from a probably >20 years old standard to an only 10 years old one :-)
From the changelog:
* Fr Apr 20 2012 crrodriguez@opensuse.org - Switch to default archive type to POSIX.1-2001, which is ten years old and has no limits on filesize,filename length etc.
files, experimenting is a lengthy process. I can't tell from the 13.1 tar man page what option might make busybox tar able to extract from a 13.1 tar file. Anyone know what's going on here?
"man 1 tar", then "/posix" You probably want "--format=gnu" or "--format=oldgnu" or even "--old-archive" or "--portability". I use the following for creating packages for my collection of STBs and it works fine with (current versions, though) of busybox: seife@susi:/local/seife/src/azbox> grep TAR= scripts/opkg.sh TAR="tar -H gnu" my busybox has the following config: seife@susi:/local/seife/src/azbox> grep ^[^#].*TAR \ archive-patches/busybox-1.19.config CONFIG_TAR=y CONFIG_FEATURE_TAR_CREATE=y CONFIG_FEATURE_TAR_AUTODETECT=y CONFIG_FEATURE_TAR_FROM=y CONFIG_FEATURE_TAR_OLDGNU_COMPATIBILITY=y CONFIG_FEATURE_TAR_GNU_EXTENSIONS=y CONFIG_FEATURE_TAR_LONG_OPTIONS=y CONFIG_FEATURE_TAR_TO_COMMAND=y CONFIG_FEATURE_TAR_NOPRESERVE_TIME=y good luck, seife -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 18.08.2013 08:18, schrieb Felix Miata:
In 13.1M4, I did
tar -cvf /mnt/usb/stuff.tar file1.ts file2.ts file3.ts
On /mnt/usb was a NTFS formatted USB stick. The object of tarring was to preserve all native file attributes while transversing the foreign
What do you understand by "native file attributes"? On ZFS, NTFS ACLs (the only ACL definition that currently appears in a standard) is part of the "native file attributes".
formatted media. After ejecting, I put it into a USB port on a Linux STB running busybox v1.0. After it automounted, I changed to the desired destination for extraction, and then
tar -xvf <mountpoint>/stuff.tar .
That gave me $SUBJECT. Apparently busybox tar isn't very smart.
Could you be a bit more verbose? Do xou like to say ty that you found a tar implementation that prints: "pax is not tar"?
It is. But busybox 1.0 is almost 10 years old. And even with current busybox you need to enable the correct options.
I've done this before successfully, making me believe something about tar in 13.1 is different. Is it? Is it a bug?
No, it's a feature. The defaults changed from a probably >20 years old standard to an only 10 years old one :-)
To which tar implementation do you believe that this applies? 1979, the originally non-free UNIX tar implementation came out (free since June 14 2005) 1982, the free "star" came out 1987, the free Public Domain tar (or Sun User Group tar) came out that later was renamed to "gtar". After 2000, the FreeBSD based "libarchive" came out.
From the changelog:
* Fr Apr 20 2012 crrodriguez@opensuse.org - Switch to default archive type to POSIX.1-2001, which is ten years old and has no limits on filesize,filename length etc.
So to which tar implementation does this apply? gtar is only similar to POSIX... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 18.08.2013 12:29, schrieb Joerg Schilling:
Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 18.08.2013 08:18, schrieb Felix Miata:
In 13.1M4, I did
From the changelog:
* Fr Apr 20 2012 crrodriguez@opensuse.org - Switch to default archive type to POSIX.1-2001, which is ten years old and has no limits on filesize,filename length etc.
So to which tar implementation does this apply?
I'll leave it to you to guess the answer by yourself. Hint: the question was asked on the *openSUSE*-factory list. Another hint: Felix mentioned the version he is using. -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 18.08.2013 12:29, schrieb Joerg Schilling:
Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 18.08.2013 08:18, schrieb Felix Miata:
In 13.1M4, I did
From the changelog:
* Fr Apr 20 2012 crrodriguez@opensuse.org - Switch to default archive type to POSIX.1-2001, which is ten years old and has no limits on filesize,filename length etc.
So to which tar implementation does this apply?
I'll leave it to you to guess the answer by yourself.
Hint: the question was asked on the *openSUSE*-factory list. Another hint: Felix mentioned the version he is using.
I see no clear hint on whether he was writing about gtar or the tar in busy box. BTW: a more or less useful POSIX-1.2001 tar support is big. Before star did include support for POSIX.1-2001, it compiled to a binary of the half size of gtar even though it had comparable features. Now star has become big (1.5x the size of gtar). One reason is that it now includes a working incremental backup system, the other is that it includes POSIX.1-2001 support. - well star also includes libfind. In general: do not expect a useful tar implementation in a binary that is optimized for size. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-08-18 12:29, Joerg Schilling wrote:
Stefan Seyfried <> wrote:
Am 18.08.2013 08:18, schrieb Felix Miata:
In 13.1M4, I did
tar -cvf /mnt/usb/stuff.tar file1.ts file2.ts file3.ts
On /mnt/usb was a NTFS formatted USB stick. The object of tarring was to preserve all native file attributes while transversing the foreign
What do you understand by "native file attributes"?
He is saving files with Linux attributes into an NTFS filesystem that does not understand them. Thus, he uses tar to encapsulate the files so that they are preserved, as the final destination is another Linux filesystem. This is a common trick. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
On 2013-08-18 08:18, Felix Miata wrote:
On /mnt/usb was a NTFS formatted USB stick.
I understand what you are doing, but perhaps, considering the size of the files, it would be faster to reformat as ext4 (without journal): mke2fs -t ext4 -L SomeName -O ^has_journal /dev/sde1 I actually have sticks formatted as ext4, ntfs, and fat... depending on destination. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
On 2013-08-18 14:14 (GMT+0200) Carlos E. R. composed:
On 2013-08-18 08:18, Felix Miata wrote:
On /mnt/usb was a NTFS formatted USB stick.
I understand what you are doing, but perhaps, considering the size of the files, it would be faster to reformat as ext4 (without journal):
mke2fs -t ext4 -L SomeName -O ^has_journal /dev/sde1
I actually have sticks formatted as ext4, ntfs, and fat... depending on destination.
1-I loath situations that necessitate use of sticks for large files. I own few, and use them only when other options are unavailable. 2-Until I started installing 64 bit operating system versions last year, I never formatted anything EXT4. For compatibility reasons, I still don't, except for some / partitions hosting 64 bit operating systems. The AZBox ultimate destination for these files runs on 2.6.15-sigma. When its menu is used to format storage, it uses EXT2. I have no idea whether it would support EXT4 at all, much less any attributes EXT4 may have acquired between 2.6.15 and 3.11 kernel versions. 3-This is my only 32GB stick, acquired for use with a STB lacking both ethernet, and eSATA, and FOSS underpinnings. It was some sort of FAT when purchased. I booted WinXP in order to reformat it with a less crippled filesystem maximally suitable for use with non-FOSS OS supporting only FAT and NTFS. 4-Choosing to tar the files to preserve attributes turned out to be a blunder. The only attributes I care about that are not easily recreated are timestamps, which is why I tried tar (not gtar, not star, but tar; BusyBox v1.00 2008.04.24-06 I must deal with has no star, no gtar). As the filesystem the original files were copied to USB from are on a HD device formatted with EXT2 and with both eSATA and USB connectivity, I should have cabled the device directly to the STB's USB port instead of having to slow copy multiply. Thanks to all 5 who replied. To Stefan, I couldn't find *src* on my AZBox HD+ except for two of its drivers, not that it would matter to me, since I'm no programmer. I saw the posix section of the tar man page. The choices given there are largely why I started this thread. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 18.08.2013 16:28, schrieb Felix Miata:
To Stefan, I couldn't find *src* on my AZBox HD+ except for two of its drivers, not that it would matter to me, since I'm no programmer. I saw the posix section of the tar man page. The choices given there are largely why I started this thread.
I'm pretty sure that you'll be able to unpack the tarball created with tar --old-archive -cvpf your.tar ./ even on the old busybox-1.0 on your box. Good luck, Stefan -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Felix Miata <mrmazda@earthlink.net> wrote:
On 2013-08-18 14:14 (GMT+0200) Carlos E. R. composed:
On 2013-08-18 08:18, Felix Miata wrote:
On /mnt/usb was a NTFS formatted USB stick.
I understand what you are doing, but perhaps, considering the size of the files, it would be faster to reformat as ext4 (without journal):
mke2fs -t ext4 -L SomeName -O ^has_journal /dev/sde1
I actually have sticks formatted as ext4, ntfs, and fat... depending on destination.
1-I loath situations that necessitate use of sticks for large files. I own few, and use them only when other options are unavailable.
If you care about large files, why don't you use FAT + star? star is able to reliably split things into a multi volume archive... just use a volume size < 4 GB for FAT.
2-Until I started installing 64 bit operating system versions last year, I never formatted anything EXT4. For compatibility reasons, I still don't, except for some / partitions hosting 64 bit operating systems. The AZBox ultimate destination for these files runs on 2.6.15-sigma. When its menu is used to format storage, it uses EXT2. I have no idea whether it would support EXT4 at all, much less any attributes EXT4 may have acquired between 2.6.15 and 3.11 kernel versions.
Ext* is only a good choice in case you never like to use anything besides Linux.
4-Choosing to tar the files to preserve attributes turned out to be a blunder. The only attributes I care about that are not easily recreated are timestamps, which is why I tried tar (not gtar, not star, but tar; BusyBox
If you are on Linux, it is most unlikely that you did ever use "tar" but rather typically gtar.
v1.00 2008.04.24-06 I must deal with has no star, no gtar). As the filesystem the original files were copied to USB from are on a HD device formatted with EXT2 and with both eSATA and USB connectivity, I should have cabled the device directly to the STB's USB port instead of having to slow copy multiply.
If you care about timestamps, did you ever think about star? Star is the first tar implementation that supports all three UNIX time stamps (star did this even before gtar exists) and star is the first tar implementation that supports the time stamps in sub-second granularity using the POSIX.1-2001 archive format. Star runs everywhere (even inside my Android phone), so I cannot think about a scenario where you cannot use it. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-08-18 19:28 (GMT+0200) Joerg Schilling composed:
Felix Miata wrote:
1-I loath situations that necessitate use of sticks for large files. I own few, and use them only when other options are unavailable.
If you care about large files, why don't you use FAT + star?
FAT: not robust star: not installed
star is able to reliably split things into a multi volume archive... just use a volume size < 4 GB for FAT.
Media file management is trouble enough without arbitrarily splitting files to keep maximum under an arbitrary size.
Ext* is only a good choice in case you never like to use anything besides Linux.
Hence why I reformatted the FAT stick NTFS instead of EXT2. I never like to use Windows. I boot it only briefly out of occasional necessity, or for fixing corrupted ones. Most NTFS usage here is from a non-FOSS STB.
If you are on Linux, it is most unlikely that you did ever use "tar" but rather typically gtar.
v1.00 2008.04.24-06 I must deal with has no star, no gtar).
AZBox $ gtar -sh: gtar: command not found $ tar BusyBox v1.00 (2008.04.24-06:54+0000) multi-call binary Usage: tar -[czjxtvO] [-f TARFILE] [-C DIR] [FILE(s)] ......
If you care about timestamps, did you ever think about star?
AZBox $ star -sh: star: command not found My AZBox has no ?tar anywhere on it that MC can find.
Star runs everywhere (even inside my Android phone), so I cannot think about a scenario where you cannot use it.
Even on this 11.4 system: # star If 'star' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf star # gtar If 'gtar' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf gtar # zypper se -s tar | egrep 'star|gtar' | egrep -v 'tart|tars|tarl|dict' | gcstar | package | 1.6.1-4.1 | noarch | OSS | star | package | 1.5final-46.1 | i586 | OSS I don't recall ever anyone in an AZBox context mentioning the possibility of gtar or star. Neither how to build software for sigma/mips, not that it would matter, since I'm not a programmer, or a builder, even using a build service. I have more than enough trouble learning how to use what others have built and provided. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Felix Miata <mrmazda@earthlink.net> wrote:
FAT: not robust
ext* is not robust from my experiences. I cannot speack for ext4, but until ext3, I had a lot of trouble with these filesystems.
Ext* is only a good choice in case you never like to use anything besides Linux.
Hence why I reformatted the FAT stick NTFS instead of EXT2. I never like to use Windows. I boot it only briefly out of occasional necessity, or for fixing corrupted ones. Most NTFS usage here is from a non-FOSS STB.
AFAIK, NTFS is not documented, so implementations besides the one from Win-DOS are a result from a more or less good reverse engineering.
If you are on Linux, it is most unlikely that you did ever use "tar" but rather typically gtar.
v1.00 2008.04.24-06 I must deal with has no star, no gtar).
AZBox $ gtar -sh: gtar: command not found
On many Linux systems, gtar is installed as "tar".
$ tar BusyBox v1.00 (2008.04.24-06:54+0000) multi-call binary
Usage: tar -[czjxtvO] [-f TARFILE] [-C DIR] [FILE(s)] ......
This is definitely no output from the original "tar" but a clone. Are you sure you may trus it?
If you care about timestamps, did you ever think about star?
AZBox $ star -sh: star: command not found
My AZBox has no ?tar anywhere on it that MC can find.
Star runs everywhere (even inside my Android phone), so I cannot think about a scenario where you cannot use it.
Even on this 11.4 system: # star If 'star' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf star # gtar If 'gtar' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf gtar # zypper se -s tar | egrep 'star|gtar' | egrep -v 'tart|tars|tarl|dict' | gcstar | package | 1.6.1-4.1 | noarch | OSS | star | package | 1.5final-46.1 | i586 | OSS
Looks like you are running an extremely outdated or unmaintained OS. star-1.5 is from April 2008. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, 18 Aug 2013 21:00:54 +0200 Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote:
$ tar BusyBox v1.00 (2008.04.24-06:54+0000) multi-call binary ... This is definitely no output from the original "tar" but a clone.
That is BusyBox, used by openSUSE during installation. http://www.busybox.net/about.html
Are you sure you may trus it?
Not more than we can trust openSUSE :) -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Rajko <rmatov101@charter.net> wrote:
On Sun, 18 Aug 2013 21:00:54 +0200 Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote: ...
This is definitely no output from the original "tar" but a clone.
That is BusyBox, used by openSUSE during installation. http://www.busybox.net/about.html
The OP does not seem to understand that with beginning to write star in 1982, "tar" is not the name of a single program but that there are more such implementations.
Are you sure you may trus it?
Not more than we can trust openSUSE :)
I do not distrust suse in general, but I would never use e.g. gtar (which appears under the name "tar" on suse) as long as I compile star within a minute. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>:
Not more than we can trust openSUSE :)
I do not distrust suse in general, but I would never use e.g. gtar (which appears under the name "tar" on suse) as long as I compile star within a minute.
sure, but are you objective on that statement? I mean: you know the author of star personally, don't you? (note: this is a rhetorical question: I know that you are the author). So, making advertisements for you inferior and error free tools is appreciated; but please mark your mails as ads please. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
"Dominique Leuenberger a.k.a. Dimstar" <dimstar@opensuse.org> wrote:
Quoting Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>:
Not more than we can trust openSUSE :)
I do not distrust suse in general, but I would never use e.g. gtar (which appears under the name "tar" on suse) as long as I compile star within a minute.
sure, but are you objective on that statement? I mean: you know the author of star personally, don't you? (note: this is a rhetorical question: I know that you are the author).
I know some of the nasty bugs in gtar, this is why I try to avoid it. If you know bugs in star, you are of course free to report them and I can guarantee that it will not take the average 15 years as with gtar to thix them. So let me ask: do you know star bugs? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2013-08-19 11:11, Joerg Schilling wrote:
I know some of the nasty bugs in gtar, this is why I try to avoid it. If you know bugs in star, you are of course free to report them and I can guarantee that it will not take the average 15 years as with gtar to thix them.
So let me ask: do you know star bugs?
It lacks a {gtar-compatible command line parsing} compatibility mode. ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt <jengelh@inai.de> wrote:
On Monday 2013-08-19 11:11, Joerg Schilling wrote:
I know some of the nasty bugs in gtar, this is why I try to avoid it. If you know bugs in star, you are of course free to report them and I can guarantee that it will not take the average 15 years as with gtar to thix them.
So let me ask: do you know star bugs?
It lacks a {gtar-compatible command line parsing} compatibility mode. ;)
Wrong claim, sorry... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> [08-19-13 05:12]: [...]
I know some of the nasty bugs in gtar, this is why I try to avoid it. If you know bugs in star, you are of course free to report them and I can guarantee that it will not take the average 15 years as with gtar to thix them.
So let me ask: do you know star bugs?
*Everything* is _not_ an affront of your efforts as a programmer but your abrasive presentation and arguments "Piss people off"! If you would guarentee attendance at a "Dale Carnegie" course, I am sure a collection to pay for the course would be quickly completed. google it. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-08-19 10:34 (GMT+0200) Joerg Schilling composed:
Rajko wrote:
Joerg Schilling wrote:
This is definitely no output from the original "tar" but a clone.
That is BusyBox, used by openSUSE during installation. http://www.busybox.net/about.html
The OP does not seem to understand that with beginning to write star in 1982, "tar" is not the name of a single program but that there are more such implementations.
I (OP) have seen no such discussion in any docs. When looking up tar, such as in a Linux reference manual (e.g. ISBN: 0-7821-2735-5 or 0-7821-2341-4), tar --help, or man tar, there's been no explicit or implicit mention that tar is anything but GNU tar, no direct or indirect mention of gtar or star posing as tar. The man page does mention a utar format, but doesn't say why it might be needed or desired. I've seen nothing prior to this thread to imply one should expect a tar file created by an x86 Linux system's installed by default tar command using the most common tar options shouldn't be expected to be extracted without special options by the installed by default tar command on another x86 Linux system, including one that substitutes busybox for a shell and individual binary tools like tar. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 8/19/2013 12:15 PM, Felix Miata wrote:
On 2013-08-19 10:34 (GMT+0200) Joerg Schilling composed:
Rajko wrote:
Joerg Schilling wrote:
This is definitely no output from the original "tar" but a clone.
That is BusyBox, used by openSUSE during installation. http://www.busybox.net/about.html
The OP does not seem to understand that with beginning to write star in 1982, "tar" is not the name of a single program but that there are more such implementations.
I (OP) have seen no such discussion in any docs. When looking up tar, such as in a Linux reference manual (e.g. ISBN: 0-7821-2735-5 or 0-7821-2341-4), tar --help, or man tar, there's been no explicit or implicit mention that tar is anything but GNU tar, no direct or indirect mention of gtar or star posing as tar. The man page does mention a utar format, but doesn't say why it might be needed or desired. I've seen nothing prior to this thread to imply one should expect a tar file created by an x86 Linux system's installed by default tar command using the most common tar options shouldn't be expected to be extracted without special options by the installed by default tar command on another x86 Linux system, including one that substitutes busybox for a shell and individual binary tools like tar.
OK I know Joerg was being a little intentionally obtuse as if he never heard of a set top box or other situation where it's not practical to compile or even install anything, asking why don't you just install star etc, but so is this. If you really never encountered a tar incompatibility before then your experience differs from mine. I would never be surprised when when default tar with default options turns out to be incompatible between implementations. gtar is gnu tar, which is just one of many different tars out there, including busybox, including other unix-like os's, including mks tools on windows, etc etc. So your set top box runs "linux", but that doesn't mean anything beyond the kernel. It's a set top box, and as is absolutely typical for embedded and appliances, it's system is not the same as a regular full desktop system and it's "tar" is really just the minimal barely useful implementation in busybox. Just like it's sh is probably not bash but ash, and many common things that work on a desktop will not work exactly the same if tried on that appliance. Stephan said it right the first time. You just need to tell gtar* to specially create a file that an older or simpler tar implementation will understand. It's normal to try the defaults first of course, and it's annoying to encounter the incompatibility, but it's not even remotely a surprise when it turned out to require some special handling in a case like this. * (yes, you are running gtar whether it says so or not, yes a user as long experienced as you is expected to know that, just like sh is really bash on every normal linux system, and just as with tar, on your set top box sh is probably NOT bash but most likely ash) This is all true of practically all of the core unix utils. There are many awks, many finds, many seds, etc... The ones on linux desktops are ususally gnu, so awk is really gawk, installed as /usr/bin/awk, and it's pretty different from anyone elses's awk, and it's even pretty different from the awk on a "linux" system that happens to be specially constructed, ie an appliance, ie probably using busybox for everything although busybox is not the only place such special versions come from either. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
"Brian K. White" <brian@aljex.com> wrote:
OK I know Joerg was being a little intentionally obtuse as if he never heard of a set top box or other situation where it's not practical to compile or even install anything, asking why don't you just install star etc, but so is this.
The first what I did with my Android phone was to install my own shell as it implements "find" as builtin via libfind. This was needed as the "ls" on Android is unusable. The next command was star...
If you really never encountered a tar incompatibility before then your experience differs from mine. I would never be surprised when when default tar with default options turns out to be incompatible between implementations. gtar is gnu tar, which is just one of many different tars out there, including busybox, including other unix-like os's, including mks tools on windows, etc etc.
star has more than 30 years of experience with creating archives that can be read by any tar implementation that is halfway correct - even if this is the oldest tar from around 1977-1979. gtar has a long history with creating incompatible archives. The last time I checked, it did create vendor specific extensions for file names
100 chars instead of the POSIX.1-1988 method even when told to be POSIX compliant.
So your set top box runs "linux", but that doesn't mean anything beyond the kernel. It's a set top box, and as is absolutely typical for embedded and appliances, it's system is not the same as a regular full desktop system and it's "tar" is really just the minimal barely useful implementation in busybox. Just like it's sh is probably not bash but ash, and many common things that work on a desktop will not work exactly the same if tried on that appliance.
When I implemented POSIX.1-2001 extensions for star in 2001, I thought about using this format as the new default, but then at that time there was not a single other implementation that could read such archives. POSIX.1-2001 extensions are nice as they e.g. support sub-second timestamp granularity but you should only use them if you are sure that you have a modern tar implementation at the extract side.
* (yes, you are running gtar whether it says so or not, yes a user as long experienced as you is expected to know that, just like sh is really bash on every normal linux system, and just as with tar, on your set top box sh is probably NOT bash but most likely ash)
You could not use a real Bourne Shell on Linux before I rewrote the Bourne Shell to use malloc() instead of sbrk() in April 2012. You could of course use ksh93 since a while (1999 IIRC). Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Brian K. White wrote:
I (OP) have seen no such discussion in any docs. When looking up tar, such as in a Linux reference manual (e.g. ISBN: 0-7821-2735-5 or 0-7821-2341-4), tar --help, or man tar, there's been no explicit or implicit mention that tar is anything but GNU tar,
The tar manpage talks about different formats that you can use (as well as supporting 2 types of incremental backups): -g, --listed-incremental=FILE handle new GNU-format incremental backup -G, --incremental handle old GNU-format incremental backup -H, --format=FORMAT create archive of the given format FORMAT is one of the following: gnu GNU tar 1.13.x format oldgnu GNU format as per tar <= 1.12 pax POSIX 1003.1-2001 (pax) format posix same as pax ustar POSIX 1003.1-1988 (ustar) format v7 old V7 tar format --old-archive, --portability same as --format=v7 --pax-option=keyword[[:]=value][,keyword[[:]=value]]... control pax keywords --posix same as --format=posix --- star used to be notably better than gnu tar (supporting ACL's and ExtAttrs) long before anything in gnu did), but with the core dumps, and gnu working to catchup... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Linda Walsh <suse@tlinx.org> wrote:
Brian K. White wrote:
I (OP) have seen no such discussion in any docs. When looking up tar, such as in a Linux reference manual (e.g. ISBN: 0-7821-2735-5 or 0-7821-2341-4), tar --help, or man tar, there's been no explicit or implicit mention that tar is anything but GNU tar,
The tar manpage talks about different formats that you can use (as well as supporting 2 types of incremental backups):
-g, --listed-incremental=FILE handle new GNU-format incremental backup -G, --incremental handle old GNU-format incremental backup
Be cyareful with these options: gtar is unable to reatore it's incrementals in case directories have been renamed in specific ways.
-H, --format=FORMAT create archive of the given format FORMAT is one of the following: gnu GNU tar 1.13.x format oldgnu GNU format as per tar <= 1.12 pax POSIX 1003.1-2001 (pax) format posix same as pax ustar POSIX 1003.1-1988 (ustar) format v7 old V7 tar format --old-archive, --portability same as --format=v7 --pax-option=keyword[[:]=value][,keyword[[:]=value]]... control pax keywords --posix same as --format=posix
--- star used to be notably better than gnu tar (supporting ACL's and ExtAttrs) long before anything in gnu did), but with the core dumps, and gnu working to catchup...
I did never see any coredump from star and you did never report such a problem, I therefore assume that such problems do not exist. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Joerg Schilling wrote:
I did never see any coredump from star and you did never report such a problem, I therefore assume that such problems do not exist.
That's fine, no coredumps were left in the CWD Already mentioned running with one of suse's latest copies from factory -- at most a few months old. with version nums and dated april this year... So the fact that suse hasn't updated their copy in 5 years, and the fact that it dumps core -- in this case before it started, .. usually it gets at least a few run... maybe (in this case) the CWD didn't exist and that causes a problem too? star: No such file or directory. Cannot change directory to '/backups/law/Documents/.'. Ishtar:law/bin> star*** buffer overflow detected ***: star terminated ======= Backtrace: ========= /lib64/libc.so.6(__fortify_fail+0x37)[0x3001cfe607] /lib64/libc.so.6[0x3001cfc6e0] star[0x4278b5] star[0x4194cc] star[0x41a1b8] star[0x41a1b8] star[0x41a1b8] star[0x41a1b8] star[0x41a1b8] star[0x41a363] star[0x406ac9] star[0x40af8c] star[0x42d681] star[0x403c75] /lib64/libc.so.6(__libc_start_main+0xf5)[0x3001c21a15] star[0x4040c9] ======= Memory map: ======== 00400000-00452000 r-xp 00000000 08:26 38345744 /usr/bin/star 00651000-00652000 r--p 00051000 08:26 38345744 /usr/bin/star 00652000-00655000 rw-p 00052000 08:26 38345744 /usr/bin/star 00655000-00679000 rw-p 00000000 00:00 0 00854000-00856000 rw-p 00054000 08:26 38345744 /usr/bin/star 018f5000-01916000 rw-p 00000000 00:00 0 [heap] 3000000000-3000021000 r-xp 00000000 08:21 50375961 /lib64/ld-2.17.so 3000221000-3000222000 r--p 00021000 08:21 50375961 /lib64/ld-2.17.so 3000222000-3000223000 rw-p 00022000 08:21 50375961 /lib64/ld-2.17.so 3000223000-3000224000 rw-p 00000000 00:00 0 3001c00000-3001da4000 r-xp 00000000 08:21 50375962 /lib64/libc-2.17.so 3001da4000-3001fa3000 ---p 001a4000 08:21 50375962 /lib64/libc-2.17.so 3001fa3000-3001fa7000 r--p 001a3000 08:21 50375962 /lib64/libc-2.17.so 3001fa7000-3001fa9000 rw-p 001a7000 08:21 50375962 /lib64/libc-2.17.so 3001fa9000-3001fad000 rw-p 00000000 00:00 0 3002000000-3002017000 r-xp 00000000 08:21 50375963 /lib64/libpthread-2.17.so 3002017000-3002216000 ---p 00017000 08:21 50375963 /lib64/libpthread-2.17.so 3002216000-3002217000 r--p 00016000 08:21 50375963 /lib64/libpthread-2.17.so 3002217000-3002218000 rw-p 00017000 08:21 50375963 /lib64/libpthread-2.17.so 3002218000-300221c000 rw-p 00000000 00:00 0 3002400000-3002403000 r-xp 00000000 08:21 50376108 /lib64/libdl-2.17.so 3002403000-3002602000 ---p 00003000 08:21 50376108 /lib64/libdl-2.17.so 3002602000-3002603000 r--p 00002000 08:21 50376108 /lib64/libdl-2.17.so 3002603000-3002604000 rw-p 00003000 08:21 50376108 /lib64/libdl-2.17.so 3003000000-3003016000 r-xp 00000000 08:21 50406465 /lib64/libgcc_s.so.1 3003016000-3003215000 ---p 00016000 08:21 50406465 /lib64/libgcc_s.so.1 3003215000-3003216000 r--p 00015000 08:21 50406465 /lib64/libgcc_s.so.1 3003216000-3003217000 rw-p 00016000 08:21 50406465 /lib64/libgcc_s.so.1 3007800000-3007820000 r-xp 00000000 08:21 50334259 /lib64/libselinux.so.1 3007820000-3007a1f000 ---p 00020000 08:21 50334259 /lib64/libselinux.so.1 3007a1f000-3007a20000 r--p 0001f000 08:21 50334259 /lib64/libselinux.so.1 3007a20000-3007a21000 rw-p 00020000 08:21 50334259 /lib64/libselinux.so.1 3007a21000-3007a23000 rw-p 00000000 00:00 0 3013a00000-3013a04000 r-xp 00000000 08:21 51558559 /lib64/libattr.so.1.1.0 3013a04000-3013c03000 ---p 00004000 08:21 51558559 /lib64/libattr.so.1.1.0 3013c03000-3013c04000 r--p 00003000 08:21 51558559 /lib64/libattr.so.1.1.0 3013c04000-3013c05000 rw-p 00004000 08:21 51558559 /lib64/libattr.so.1.1.0 3016200000-3016208000 r-xp 00000000 08:21 51558572 /lib64/libacl.so.1.1.0 3016208000-3016407000 ---p 00008000 08:21 51558572 /lib64/libacl.so.1.1.0 3016407000-3016408000 r--p 00007000 08:21 51558572 /lib64/libacl.so.1.1.0 3016408000-3016409000 rw-p 00008000 08:21 51558572 /lib64/libacl.so.1.1.0 3024200000-3024215000 r-xp 00000000 08:21 52166343 /lib64/libnsl-2.17.so 3024215000-3024414000 ---p 00015000 08:21 52166343 /lib64/libnsl-2.17.so 3024414000-3024415000 r--p 00014000 08:21 52166343 /lib64/libnsl-2.17.so 3024415000-3024416000 rw-p 00015000 08:21 52166343 /lib64/libnsl-2.17.so 3024416000-3024418000 rw-p 00000000 00:00 0 3077a00000-3077a61000 r-xp 00000000 08:21 50839512 /lib64/libpcre.so.1.2.0 3077a61000-3077c60000 ---p 00061000 08:21 50839512 /lib64/libpcre.so.1.2.0 3077c60000-3077c61000 r--p 00060000 08:21 50839512 /lib64/libpcre.so.1.2.0 3077c61000-3077c62000 rw-p 00061000 08:21 50839512 /lib64/libpcre.so.1.2.0 7f678d8eb000-7f678d8f1000 r-xp 00000000 08:21 34193957 /lib64/libnss_winbind.so.2 7f678d8f1000-7f678daf0000 ---p 00006000 08:21 34193957 /lib64/libnss_winbind.so.2 7f678daf0000-7f678daf1000 r--p 00005000 08:21 34193957 /lib64/libnss_winbind.so.2 7f678daf1000-7f678daf2000 rw-p 00006000 08:21 34193957 /lib64/libnss_winbind.so.2 7f678daf2000-7f678daf7000 rw-p 00000000 00:00 0 7f678daf7000-7f678db01000 r-xp 00000000 08:21 50834106 /lib64/libnss_nis-2.17.so 7f678db01000-7f678dd00000 ---p 0000a000 08:21 50834106 /lib64/libnss_nis-2.17.so 7f678dd00000-7f678dd01000 r--p 00009000 08:21 50834106 /lib64/libnss_nis-2.17.so 7f678dd01000-7f678dd02000 rw-p 0000a000 08:21 50834106 /lib64/libnss_nis-2.17.so 7f678dd02000-7f678dd09000 r-xp 00000000 08:21 50834082 /lib64/libnss_compat-2.17.so 7f678dd09000-7f678df08000 ---p 00007000 08:21 50834082 /lib64/libnss_compat-2.17.so 7f678df08000-7f678df09000 r--p 00006000 08:21 50834082 /lib64/libnss_compat-2.17.so 7f678df09000-7f678df0a000 rw-p 00007000 08:21 50834082 /lib64/libnss_compat-2.17.so 7f678df0a000-7f678df16000 r-xp 00000000 08:21 50834100 /lib64/libnss_files-2.17.so 7f678df16000-7f678e115000 ---p 0000c000 08:21 50834100 /lib64/libnss_files-2.17.so 7f678e115000-7f678e116000 r--p 0000b000 08:21 50834100 /lib64/libnss_files-2.17.so 7f678e116000-7f678e117000 rw-p 0000c000 08:21 50834100 /lib64/libnss_files-2.17.so 7f678e117000-7f679e159000 rw-s 00000000 00:04 21367880 /dev/zero (deleted) 7f679e159000-7f679e15e000 rw-p 00000000 00:00 0 7f679e1bd000-7f679e1be000 rw-p 00000000 00:00 0 7f679e1be000-7f679e1bf000 rw-p 00000000 00:00 0 7fff0b445000-7fff0b47a000 rw-p 00000000 00:00 0 [stack] 7fff0b55f000-7fff0b560000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Linda Walsh <suse@tlinx.org> wrote:
Joerg Schilling wrote:
I did never see any coredump from star and you did never report such a problem, I therefore assume that such problems do not exist.
That's fine, no coredumps were left in the CWD
Already mentioned running with one of suse's latest copies from factory -- at most a few months old. with version nums and dated april this year... So the fact that suse hasn't updated their copy in 5 years, and the fact that it dumps core -- in this case before it started, .. usually it gets at least a few run... maybe (in this case) the CWD didn't exist and that causes a problem too?
star: No such file or directory. Cannot change directory to '/backups/law/Documents/.'. Ishtar:law/bin> star*** buffer overflow detected ***: star terminated ======= Backtrace: ========= /lib64/libc.so.6(__fortify_fail+0x37)[0x3001cfe607] /lib64/libc.so.6[0x3001cfc6e0] star[0x4278b5] star[0x4194cc] star[0x41a1b8] star[0x41a1b8]
Sorry, but if you cannot send at least a stacktrace with function names, I cannot help. But with the top of stack, this may be a bug in glibc that caused the problem. Does this happen with a recent star? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Joerg Schilling wrote:
Linda Walsh <suse@tlinx.org> wrote:
Joerg Schilling wrote:
I did never see any coredump from star and you did never report such a problem, I therefore assume that such problems do not exist.
That's fine, no coredumps were left in the CWD
Already mentioned running with one of suse's latest copies from factory -- at most a few months old. with version nums and dated april this year... So the fact that suse hasn't updated their copy in 5 years, and the fact that it dumps core -- in this case before it started, .. usually it gets at least a few run... maybe (in this case) the CWD didn't exist and that causes a problem too?
star: No such file or directory. Cannot change directory to '/backups/law/Documents/.'. Ishtar:law/bin> star*** buffer overflow detected ***: star terminated ======= Backtrace: ========= /lib64/libc.so.6(__fortify_fail+0x37)[0x3001cfe607] /lib64/libc.so.6[0x3001cfc6e0] star[0x4278b5] star[0x4194cc] star[0x41a1b8] star[0x41a1b8]
Sorry, but if you cannot send at least a stacktrace with function names, I cannot help.
Why do you think I didn't send in a bug report. You've disabled coredumps but then expect the user to send tracebacks? It's hard enough to send in bug reports, and get shat on for not having a development system that is equivalent to a sterile build environment, but when programs turn off stack tracing but then require it for bug reports, it gets to be too much of a bother. It's too bad too, as I wouldn't have run into the error if I wasn't using it (had it running in a cron job for, at least, a few years, before it started failing -- likely anything above opensuse 11.3. Why would you, as a developer, turn off coredumps, but then require them for bug reporting. You said before, no one has reported these bugs that have been in the product for at least 3-4 years, maybe no one else wants to deal with the problems in generating things that you have disabled (unless suse did it for all products, but that would seem unbelievably irresponsible, so I may be erring on the side of naivety)... If you want to claim your program works reliably, not turning off coredumps and making sure large vendors like suse have your latest work and not a 5-yro copy would be great place to start.
Does this happen with a recent star?
Is there an alternate SuSE repo that has a newer one? AFAIK, the one in factory is the latest version. As mentioned, it's only 4 months old -- have you made any changes that would fix this in the past 4 months? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2013-08-22 00:16, Linda Walsh wrote:
Sorry, but if you cannot send at least a stacktrace with function names, I cannot help.
---- Why do you think I didn't send in a bug report. You've disabled coredumps but then expect the user to send tracebacks?
star does not disable coredumps (at least I can find no such instance in the source on a short grep), so stop accusing the wrong people. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
On Thursday 2013-08-22 00:16, Linda Walsh wrote:
Sorry, but if you cannot send at least a stacktrace with function names, I cannot help.
Why do you think I didn't send in a bug report. You've disabled coredumps but then expect the user to send tracebacks?
star does not disable coredumps (at least I can find no such instance in the source on a short grep), so stop accusing the wrong people.
I did mention that possibility...
that you have disabled (unless suse did it for all products, but that would seem unbelievably irresponsible, so I may be erring on the side of naivety)...
but couldn't imagine a linux vendor doing something so irresponsible...even MS sends coredump info back for analysis... ---- Ah... you need to be more thorough on your grep's. The Backtrace included in my message is from HIS code catching the error that would have led to a core dump. If he wanted symbols and function names -- he should talk to himself about that -- since it is his code that is printing the stack trace. --- So, I not only "cover" your accusation of me accusing the with a counter accusation against you for wrongly dismissing the accusations, but raise the absurdity level of the Joerg, complaining about lack of symbols in his OWN stack backtrace program -- and saying he won't take any error reports based on his own error output that traps and prevents a coredump that could give him the error info he wants! ;-) (I hope you are finding this silliness as amusing as I am... i.e. -- the SW has bugs, I already said it was a good program, and the fact that I can generate the error so quickly should be a sign that I already had a scripted example -- i.e. my old backup script for my doc dir. It still runs periodically on the premise that if something random caused it to break and dump core, who knows, the next update might change that.) Also, when I first got the core dumps multiple years ago, I did look for newer versions but it didn't appear that development was still active and I found no newer versions. If that's changed, great! Maybe the new version can go into SuSE factory so it can update the one that is there? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2013-08-22 02:14, Linda Walsh wrote:
that you have disabled (unless suse did it for all products, but that would seem unbelievably irresponsible, so I may be erring on the side of naivety)...
but couldn't imagine a linux vendor doing something so irresponsible...
If you think so lowly of openSUSE, then you should just quit.
even MS sends coredump info back for analysis...
In light of the NSA revealings, not *sending* coredumps by default on Linux seems a godsend. Of course only to those concerned, the rest will ignore it.
---- So, I not only "cover" your accusation of me accusing the with a counter accusation against you for wrongly dismissing the accusations, but raise the absurdity level of the Joerg, complaining about lack of symbols in his OWN stack backtrace program
Your funny quoting style aside, two (independent) things: 1. openSUSE has coredumps disabled by default - and you probably did not turn it on, 2. debug symbols are in a separate package - whicih you probably did not install either - causing backtrace functions to not be able to print anything useful in the "default install" (much to the dismay of Jörg, but whatever). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt wrote:
On Thursday 2013-08-22 02:14, Linda Walsh wrote:
that you have disabled (unless suse did it for all products, but that would seem unbelievably irresponsible, so I may be erring on the side of naivety)... but couldn't imagine a linux vendor doing something so irresponsible...
If you think so lowly of openSUSE, then you should just quit.
Those are YOUR thoughts and feelings. They are not based in what I said. To the contrary, I said I *couldn't imagine* openSuSE doing that. AFAIK, they didn't. My system settings say the default is to allow coredumps. I'm sorry, but now you are making stuff up and telling me that I should do something based on something you made up (which has nothing to do with what I said).
even MS sends coredump info back for analysis...
In light of the NSA revealings, not *sending* coredumps by default on Linux seems a godsend. Of course only to those concerned, the rest will ignore it.
In light of the NSA revealings, they already have access to virtually everything on your system, so *sending* coredumps or not, is rather irrelevant, not to mention it's probably less of an issue with Linux than with windows where they likely have automated tools that were created w/the help of MS. The fact that people fall all over themselves with the NSA approved SELINUX security, and that it is built into all of the programs and utilities whether you use it or not, worries me considerably more than concerns about them pouring through core dumps. Ever seen a SuSE build w/o the NSA-approved SELINUX hooks and libs required to be linked & loaded?
---- So, I not only "cover" your accusation of me accusing the with a counter accusation against you for wrongly dismissing the accusations, but raise the absurdity level of the Joerg, complaining about lack of symbols in his OWN stack backtrace program
Your funny quoting style aside, two (independent) things:
1. openSUSE has coredumps disabled by default - and you probably did not turn it on,
Interesting -- my /etc/sysconfig/ulimit has: ## Type: string ## Default: "unlimited" # # Limit the size of core dump files. 0 turns them off. # Hard limit: Can not be increased by non-root. # Corresponds to ulimit -Hc. # Parameter is in blocks (1k), 0 means turning core files off. # HARDCORELIMIT='unlimited' Did this change come recently? It seems 'filesystem-12.3' owns that file. Besides that point, I *do* get coredumps with other programs, when I don't it's because the application has disabled them.
2. debug symbols are in a separate package - whicih you probably did not install either - causing backtrace functions to not be able to print anything useful in the "default install" (much to the dismay of Jörg, but whatever).
When I get a coredump, and want to print a stack trace, I know to do that. This is a case where the normal function of the program is impeded or broken because it assumes those symbols will be there. So the reason there are no symbols in Joerg's default output is because openSuSE didn't ensure the programs dependencies were installed along with the program. Maybe Joerg's next OSuse release will have an explicit dependency for the debug symbols in his rpm or in the binary... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 21 Aug 2013 18:24:53 -0700 Linda Walsh <suse@tlinx.org> wrote:
Maybe Joerg's next OSuse release will have an explicit dependency for the debug symbols in his rpm or in the binary...
I don't want that. If there is a problem, I know how to install debug symbols, no need to have them installed all the time. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt <jengelh@inai.de> wrote:
2. debug symbols are in a separate package - whicih you probably did not install either - causing backtrace functions to not be able to print anything useful in the "default install" (much to the dismay of Jörg, but whatever).
This is also a problem with missing features in the GNU debug chain. gdb is not a first class debugger. adb and mdb (and the non OSS dbx from the Solaris studio) could help more. Let me give an example: cp OBJ/i386-sunos5-cc/sh /tmp # This is my enhanced portable Bourne Shell strip /tmp/sh cd /tmp /tmp/sh pstack $$ 1496: /tmp/sh feec2e75 waitid (0, 5d9, 80475a0, 83) fee72015 waitpid (5d9, 804764c, 80, 8061779) + 65 0806178d sh_waitjob (80a7c80, 1, 80476c8, 806aeae) + 51 0806b074 execute (808f85c, 0, 0, 0, 0, 2) + 85c 0806492c exfile (0) + 1ac 08064768 main (1, 804778c, 8047794, feffb8f4) + 6dc 08059a4d _start (1, 80478a0, 0, 80478a8, 80478b3, 80478c1) + 7d gcore $$ gcore: core.1496 dumped $ pstack core.1496 core 'core.1496' of 1496: /tmp/sh feec2e75 waitid (0, 5da, 80475a0, 83) fee72015 waitpid (5da, 804764c, 80, 8061779) + 65 0806178d sh_waitjob (80a7438, 1, 80476c8, 806aeae) + 51 0806b074 execute (808f85c, 0, 0, 0, 0, 2) + 85c 0806492c exfile (0) + 1ac 08064768 main (1, 804778c, 8047794, feffb8f4) + 6dc 08059a4d _start (1, 80478a0, 0, 80478a8, 80478b3, 80478c1) + 7d nm /tmp/sh /tmp/sh: Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Linda Walsh <suse@tlinx.org> wrote:
Sorry, but if you cannot send at least a stacktrace with function names, I cannot help.
---- Why do you think I didn't send in a bug report.
This is simple: I did not get a bug report, so it is obvious that you did not send one. Given the fact that you did not even send the command line that caused your problem makes it highly probable that you did not send any other bugreport before.
You've disabled coredumps but then expect the user to send tracebacks?
This happened on your computer, it seems that you disabled coredumps.
Does this happen with a recent star?
Is there an alternate SuSE repo that has a newer one? AFAIK, the one in factory is the latest version. As mentioned, it's only 4 months old -- have you made any changes that would fix this in the past 4 months?
You did not verify that you did get this problem with a _recent_ version of star. If you did get the problem with star-1.5.2 or later, please send succifient information to allow to repeat the problem (or give sufficient debug information to understand what happened) which is a condition for being able to create a fix. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 8/20/2013 9:38 PM, Linda Walsh wrote:
Brian K. White wrote:
I (OP) have seen no such discussion in any docs. When looking up tar, such as in a Linux reference manual (e.g. ISBN: 0-7821-2735-5 or 0-7821-2341-4), tar --help, or man tar, there's been no explicit or implicit mention that tar is anything but GNU tar,
I wrote no such thing. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Felix Miata <mrmazda@earthlink.net> wrote:
The OP does not seem to understand that with beginning to write star in 1982, "tar" is not the name of a single program but that there are more such implementations.
I (OP) have seen no such discussion in any docs. When looking up tar, such as in a Linux reference manual (e.g. ISBN: 0-7821-2735-5 or 0-7821-2341-4), tar
Send a bug report to the gtar people. Star's documentation mentions PD-TAR aka SUG-tar that later was renamed to gtar as the second free tar implementation and explains that PD-TAR/SUG-tar was closer to the standard than gtar.
--help, or man tar, there's been no explicit or implicit mention that tar is
The "real" tar does not implement --help.
anything but GNU tar, no direct or indirect mention of gtar or star posing as
GNU tar is not tar, it does not even correctly implement the SUSv2 tar standard CLI - regardless on thether called as "tar" or "gtar". star on the other side correctly implements the SUSv2 standard CLI in case star was called as "tar". Star implements the gtar deviations if the basename in argv[0] begins with a "g". I entered this thread because many people on Linux don't know that Linux does not deliver a real tar but gtar installed as "tar" even though star installed as tar would cause less problems. Well, there is a general problem, on Linux: people write scripts that call "tar" using a commandline that would never be accepted by a compliant tar implementation. Typical Linux problems could be dramatically reduced if Linux did install gtar as gtar and if scripts that expect the gtar CLI called gtar instead of calling tar.
tar. The man page does mention a utar format, but doesn't say why it might be needed or desired. I've seen nothing prior to this thread to imply one should
The gtar man page is not optimal. Star by default creates ustar (POSIX.1-1988) compliant archives by default since 1994. All tar implementations that failed with that tar archive format have been proven not to follow even the basic tar archive format rules from 1977 - this included gtar at that time (PD-tar was OK).
expect a tar file created by an x86 Linux system's installed by default tar command using the most common tar options shouldn't be expected to be extracted without special options by the installed by default tar command on another x86 Linux system, including one that substitutes busybox for a shell and individual binary tools like tar.
Let me repeat: busybox does not include the real tar but an own potentially buggy implementation. If you like to know whether your problem was caused by the archive format created by gtar or by the "tar" implementation in busybox, you would need to provide a sample archive for investigation. If you like to do this by your own, you could get star sources, compile them and call the included "tartest" program that tests for archive compliance. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 8/20/2013 5:58 AM, Joerg Schilling wrote:
star on the other side correctly implements the SUSv2 standard CLI in case star
I know it sounds like he's just selling his thing, and I know a recommendation that involves installing _anything_ on your set top box is simply a waste of breath since it's simply not an option, but, setting that and the immediate stb problem aside, just for the record star really is quite good. There is a reason I've been maintaining my own builds of it for SCO Unix (OSR5) and linux and freebsd for at least 10 years and it's been a core part of our backups and cross platform portability all that time with never one hitch. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2013-08-20 11:58, Joerg Schilling wrote:
Well, there is a general problem, on Linux: people write scripts that call "tar" using a commandline that would never be accepted by a compliant tar implementation. Typical Linux problems could be dramatically reduced if Linux did install gtar as gtar and if scripts that expect the gtar CLI called gtar instead of calling tar.
So, should GNU ls be installed as gls instead and ls be an implementation that does not recognize most of the options we have come to find useful? That would, rather than reduce, issue new problems. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt <jengelh@inai.de> wrote:
On Tuesday 2013-08-20 11:58, Joerg Schilling wrote:
Well, there is a general problem, on Linux: people write scripts that call "tar" using a commandline that would never be accepted by a compliant tar implementation. Typical Linux problems could be dramatically reduced if Linux did install gtar as gtar and if scripts that expect the gtar CLI called gtar instead of calling tar.
So, should GNU ls be installed as gls instead and ls be an implementation that does not recognize most of the options we have come to find useful? That would, rather than reduce, issue new problems.
As long as you have no other ls on the system and as long as the ls you are taling about is POSIX compliant, you may install it as "ls" too. The problem with the missing options and the missing features is well known by people who run "Indiana" (Sun's OpenSolaris distro). This distro (and most likely "ClosedSolaris 11 from Oracle" too) for unknown reasons has /usr/gnu/bin before /usr/bin in PATH and people who call "ls" will accidently call gls as "ls and thus not get ACL support. Many options will not work too. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Sun, 18 Aug 2013, Joerg Schilling wrote:
Felix Miata <mrmazda@earthlink.net> wrote:
FAT: not robust
ext* is not robust from my experiences. I cannot speack for ext4, but until ext3, I had a lot of trouble with these filesystems.
Huh? What FS out there is more robust on a Linux desktop machine(!) than ext*? I've had hardware lockup _bad_ and sectors going astray, but I've never had a broken filesystem (sure, files were lacking the content of the bad sectors, but the FS was just fine). And I had trouble with reiserfs3 (called it "Reißwolffs"[1][2]). Oh, unless of course, you tested ext3/ext4 while they each were brand new. I only switched to ext3 (or rather activated journaling by 'tune2fs -j') once I considered it rock stable, IIRC that was when ext4 was out already or 3-4 years after it being non-experimental in the kernel or so). New FSs were created as ext3 after that of course and on the SSD I do use ext4. So, what more robust FS is there to use? XFS, JFS and ZFS sure have their use cases, as have various Network-FSs, but the "linux desktop" is usually not one of them. Have you tested btrfs yet? 2 years ago? [..]
$ tar BusyBox v1.00 (2008.04.24-06:54+0000) multi-call binary
Usage: tar -[czjxtvO] [-f TARFILE] [-C DIR] [FILE(s)] ......
This is definitely no output from the original "tar" but a clone. Are you sure you may trus it?
Are you kidding us? You do not know what busybox is??? You definitely should have a look over the rim of your plate once in a decade. http://en.wikipedia.org/wiki/BusyBox And, while we're at it: http://en.wikipedia.org/wiki/Stand-alone_shell Jörg, I'm thankful for you writing cdrecord et. al., but you shamelessly plugging star here and now, while misunderstanding the issue with busybox's tar, is ... kind of sad. Why don't you go troll the *buntu fora for a while? -dnh [1] though I do use it now on a loop-mounted image for my newsspool [2] one of the reasons besides the obvious breakage from bad sectors is reiserfs(ck) going bonkers if it finds e.g. an image of a reiserfs on a reiserfs partition. -- Keep your fights clean and your sex dirty. -- Kevin Bacon on keeping a successful marriage -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2013-08-19 17:29, David Haller wrote:
Hello,
On Sun, 18 Aug 2013, Joerg Schilling wrote:
Felix Miata <mrmazda@earthlink.net> wrote:
FAT: not robust
ext* is not robust from my experiences. I cannot speack for ext4, but until ext3, I had a lot of trouble with these filesystems.
Huh? What FS out there is more robust on a Linux desktop machine(!) than ext*? So, what more robust FS is there to use?
Arguably one that has checksumming and some form of redundancy-on-a-single-disk should your disk endure any form of casual corruption. At least the latter part is not something I find in ext as of version ext4. btrfs would fit the bill, as would ZFS. (Since you said Linux, I'll bite: zfs-fuse.) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Joerg Schilling wrote:
Looks like you are running an extremely outdated or unmaintained OS. star-1.5 is from April 2008.
J�rg
--- That's the latest suse version I have as well (mine is from factory): Name : star Version : 1.5final Release : 59.1 Architecture: x86_64 Install Date: Fri 26 Apr 2013 09:02:09 PM PDT Group : Productivity/Archiving/Backup Size : 1081072 License : CDDL-1.0 Signature : RSA/SHA256, Thu 21 Mar 2013 02:27:02 PM PDT, Key ID b88b2fd43dbdc284 Source RPM : star-1.5final-59.1.src.rpm Build Date : Thu 21 Mar 2013 02:26:43 PM PDT Build Host : build09 Relocations : (not relocatable) Packager : http://bugs.opensuse.org Vendor : openSUSE URL : http://cdrecord.berlios.de/old/private/star.html Summary : POSIX.1-2001-Compliant Tar Implementation Description : Star is a tar like archiver. TAR stands for Tape ARchiver. Star is the fastest known implementation of a tar archiver. ---- I was jazzed about star -- until it started reliably dumping core anytime I tried to dump my docs dir... Been that way for about 3-4 years... but given how SUSE hasn't seen an update for 5, that's not surprising. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Linda Walsh <suse@tlinx.org> wrote:
Joerg Schilling wrote:
Looks like you are running an extremely outdated or unmaintained OS. star-1.5 is from April 2008.
J???rg
--- That's the latest suse version I have as well (mine is from factory): Name : star Version : 1.5final Release : 59.1 Architecture: x86_64 Install Date: Fri 26 Apr 2013 09:02:09 PM PDT Group : Productivity/Archiving/Backup Size : 1081072 License : CDDL-1.0 Signature : RSA/SHA256, Thu 21 Mar 2013 02:27:02 PM PDT, Key ID b88b2fd43dbdc284 Source RPM : star-1.5final-59.1.src.rpm Build Date : Thu 21 Mar 2013 02:26:43 PM PDT Build Host : build09 Relocations : (not relocatable) Packager : http://bugs.opensuse.org Vendor : openSUSE URL : http://cdrecord.berlios.de/old/private/star.html Summary : POSIX.1-2001-Compliant Tar Implementation Description : Star is a tar like archiver. TAR stands for Tape ARchiver. Star is the fastest known implementation of a tar archiver.
---- I was jazzed about star -- until it started reliably dumping core anytime I tried to dump my docs dir...
I have never seen any coresump from star, if you really have problems why didn't you send a bugreport? But the usual reaction on software probplems is to upgrade to the latest version first. Why didn't you do that?
Been that way for about 3-4 years... but given how SUSE hasn't seen an update for 5, that's not surprising.
Suse did not get an update since the last 5 years? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>:
Linda Walsh <suse@tlinx.org> wrote:
Been that way for about 3-4 years... but given how SUSE hasn't seen an update for 5, that's not surprising.
Suse did not get an update since the last 5 years?
Indeed, openSUSE ( the pdistribution; not SUSE, the company) still has version 1.5 in the repositories; seems nobody gives a lot of attention on the release 1.5.2 from January. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
[snip'ing everything]
Guys, I've been away for two weeks and reading this thread gives me a very nice right-back-at-home feel. It had everything a good Factory thread should have: love, hate, flames, history lessons, smartass'ing, pointers to unpackaged software and POSIX standards (I missed an RFC though), even ISBN numbers and lastly, no resolution. This is what I call perfect e-mail entertainment. I want more of that! p.s. To my knowledge I'm the only one replying to this thread that is yet under 30 and thus I don't trust anything that was written here that isn't yet found on Wikipedia ;-) -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
Sascha Peilicke <speilicke@suse.com> wrote:
[snip'ing everything]
Guys, I've been away for two weeks and reading this thread gives me a very nice right-back-at-home feel. It had everything a good Factory thread should have: love, hate, flames, history lessons, smartass'ing, pointers to unpackaged software and POSIX standards (I missed an RFC though), even ISBN numbers and lastly, no resolution. This is what I call perfect e-mail entertainment. I want more of that!
p.s. To my knowledge I'm the only one replying to this thread that is yet under 30 and thus I don't trust anything that was written here that isn't yet found on Wikipedia ;-)
I no longer remember the exact content of the discussion, so I cannot comment the first paragraph. Regarding Wikipadia: don't trust Wikipedia, Wikipedia is dominated by people that are interested in political content rather than on correct text. TAR is 34 years old, the oldest "free" implementation (star) is 31 years old and Wikipedia mentiones "pax" but an own article is prevented by those political people. I am working with UNIX since 31 years and this is the reason why I had the chance to learn a lot of the background information that helps to understand things that do not look reasonable in the first view. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 09/02/2013 09:22 PM, Joerg Schilling wrote:
Sascha Peilicke <speilicke@suse.com> wrote:
[snip'ing everything]
Guys, I've been away for two weeks and reading this thread gives me a very nice right-back-at-home feel. It had everything a good Factory thread should have: love, hate, flames, history lessons, smartass'ing, pointers to unpackaged software and POSIX standards (I missed an RFC though), even ISBN numbers and lastly, no resolution. This is what I call perfect e-mail entertainment. I want more of that!
p.s. To my knowledge I'm the only one replying to this thread that is yet under 30 and thus I don't trust anything that was written here that isn't yet found on Wikipedia ;-)
I no longer remember the exact content of the discussion, so I cannot comment the first paragraph.
Regarding Wikipadia: don't trust Wikipedia, Wikipedia is dominated by people that are interested in political content rather than on correct text.
It's an 80% solution, true. But I was joking anyway :-)
TAR is 34 years old, the oldest "free" implementation (star) is 31 years old and Wikipedia mentiones "pax" but an own article is prevented by those political people. I am working with UNIX since 31 years and this is the reason why I had the chance to learn a lot of the background information that helps to understand things that do not look reasonable in the first view.
Jörg
-- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
participants (12)
-
Brian K. White -
Carlos E. R. -
David Haller -
Dominique Leuenberger a.k.a. Dimstar -
Felix Miata -
Jan Engelhardt -
Joerg Schilling -
Linda Walsh -
Patrick Shanahan -
Rajko -
Sascha Peilicke -
Stefan Seyfried