Re: [Cdrecord-support] cdrtools-2.01.01a27 ready
Joerg Schilling wrote:
Just fact, O.P. couldn't unpack, I had some people who got stuff from me
and couldn't unpack.
Bill Davidsen <firstname.lastname@example.org> wrote:
exceptions.TypeError: stat() argument 1 must be (encoded string without NULL
bytes), not str
star generates output which can not always be read with standard
distribution tar programs. One of the reasons we stopped using it, we
need to write files people can read without having to download a package
which was in star format the last time we looked. I think it requires
some obscure POSIX tar feature no one else uses.
meaning one directory has NULL in it somehow. Any idea how this happened?
Unpacking the tarball with tar and repackaging fixes the problem but
according to docs a filename should not contain NULL (POSIX wise).
In other words it's technically "standard" but it's not useful for
distribution, only for backups.
Come on, do you need to spread this kind of FUD?
star creates archives that can be extracted by any halfway bug-free tar
Unfortunately the world is full of tar implementations which don't live
up to your standards.
Star is the best solution since 25 years.
Since that's opinion, I won't comment. I said it worked well for backups
to be read by star, but I would not recommend it for creating
distribution tar files.
You are trying to make star responsible for problems from broken tar
implementations. Check the "error message" from the original mail and
you see that this poor "tar" implementaion must have a heavy bug.
It may be buggy as an outhouse rat, but it's the tool he has.
Look at GNU tar - I need to _strongly_ recommend using GNU tar for
creating software distributions.
I'm glad you agree that GNU tar is the one to use in that case.
- GNU tar often has problems to unpack it's own archives.
People need to use star in these cases. If you read the GNU tar
mailing list, you know what I am talking of....
My use dates back to the early Linux days, and I have not had such a
problem. I'm not saying it doesn't exist, just that I have NEVER
personally had a failure of an uncorrupted gnu tar output.
- Mysql uses GNU tar to create their distribution and publish
archives that are so extremely broken, that only some GNU tar
version can unpack them.
Having unpacked on RH8, 9, and FC1, FC3. FC4 and FC6, I repeat that
it's not a common problem even if you can identify some broken tar which
doesn't unpack. You don't want star blamed for broken unpackers, yet you
seem to be blaming GNU tar for the same thing. I assume "only some GNU
tar versions" means the ones which some distribution didn't screw up.
Bill Davidsen <email@example.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot