13 Dec
2011
13 Dec
'11
5:47 p.m.
On 12/13/2011 5:16 PM, Dave McGuire wrote:
On 12/13/2011 07:51 PM, Liam Proven wrote:
Dave,
In applications where traceability is required keeping the original
goods, and probably md5sums or sha256sums around to verify them is
probably a necessity. The complaint here seems to be something you get
around once then remember it does this and deal with it.
We use tar gz for the reason that it does keep the original around, and
also because tar will verify if you use the right incantation, so you
don't have to gen up something to verify you have a package in a tar
file installed as far having to extract and diff the results.
However we did have some number of issues getting a tool which creates
SD card images (sorry, new tech, but old method) working so we not only
did the verify with tar, but also had a tool which would do a full
md5sum of all the files (not for traceability, but for diagnosing why
the image was getting damaged). It was a big pain to do what tar does
for you as far as verifying.
There are lots of things that the unix tools do, but if you use things
for enough years you remember either the specific warts you don't like,
or that they are there and look them up. I have a blog I log all my
gripes to so I don't have to google forever and have the notes for
various tricks handy.
Jim
What I expect, want and demand:
It unpacks to the name(s) of the file(s) [and folders] in the archive
and leaves the original archive the fsck alone.
In my early Linux days, I was /very/ annoyed several times when Gunzip
cheerfully *removed the archive I told it to unpack*. This is
*absolutely* unacceptable to my mind.
Why? Because it differs from another tool that you may have been
accustomed to? If that's why, be aware that gzip's user interface is
patterned after a tool that far predates pkzip/pkarc/arc/etc, and that
behavior has been the accepted one that has been considered logical
and good since the 1970s.
Also be advised that you didn't tell it to unpack an archive
(something gzip doesn't do), you told it to decompress a compressed
file. Tar (say) doesn't remove a tar file after extracting its
contents, because...well, cheerfully removing the archive you told it
to unpack would be absolutely unacceptable.
Decompressing a compressed file is a whole different animal; you can
get things right back where they were (if you need to) with a single
command. The only possible difference is the original user's
compression setting, and I respectfully submit that the loss of that
information isn't frequently a big deal.
File compression is something that you "do" to a single file.
Should "undoing" it result in two copies of the file, one with it
"done" and the other with it "undone"? THAT seems ridiculous to me.
-Dave