[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RAR under linux: any alternative?

On Mon, 2005-12-12 at 21:47 -0600, Mike McCarty wrote:
> This is not quite true. Usually, with a disc file or a file transmitted
> over a link of some sort, a block of bytes gets corrupted, usually with
> a size on the order of 1KB. If an archive is much larger than 1KB (the
> usual case, in my experience) then most of the archive may actuallly
> be usable. If each file contained in the archive has a separate
> redundancy check, then one may be able (in my experience, usually can)
> do a partial recovery, and extract some of the information. In one case,
> I had backups which got corrupted (due to a virus overwriting sectors
> on floppy discs). I had the same file corrupted in different places,
> and was able to recover the entire archive (it was a PKZIPped archive)
> by doing partial recovery on two different backups of the same archive.

This is a good point. But this is also not a feature specific to RAR, as
you point out. Zip archives, among others, can do this as well.

> Why do you suppose we put cyclic redundancy checks into messages
> used in various protocols, like FTP, TCP, IP, MTP, etc? By your
> reasoning, ISTM, you would view such cyclic redundancy checks to
> be invalid. They should be sent via a separate message. But then
> what checks the separate messages? Or in your case, what checks
> the separate files? How do you know your separate files containing
> the redundancy checks aren't corrupt? Do you have another set of
> files checking the check files? And what checks the check check files?
> To put it another way, are you aware that hard discs have redundancy
> in them to allow one to recover corrupted sectors? By your reasoning,
> this could not be put on the same disc, it would have to be on
> another disc.

Yes, but CRC checks on packets of data (a few kilobytes at a time) are
much different than a checksum on a 10, 20, or 50 MB archive,
particularly when speaking in terms of a lower-bandwidth connection.
It's easy enough to resend a TCP/IP packet if the CRC check fails.
However, we want to AVOID resending a 50 MB file if the checksum doesn't
agree with the file. It's much easier to re-download a 1K checksum file
than a 50 MB archive.

WRT to your statement about hard drives, I believe the feature you're
referring to is the ability to ignore bad sectors, not recover data from
them. If the drive determines a particular sector to be bad, it will
mark it as being bad and write the data elsewhere. If the data has
already been written to a sector, and that sector subsequently goes bad
I'm not aware of any low-level features to allow the recovery of that
sector after the fact.

> (1) the ability to open and extract files from previously created RAR
> format archives, and (2) the exchange of files with people who as a
> customary practice use that format for archiving and compression
> and prefer to send and receive them in that format.

(1) unrar-free would do this as well
(2) see below

> I can't control my neighbor's dog, let alone my neighbor. If
> someone I am doing a contract for requests RAR format, then
> that's what he'll get, and I won't argue. I consider putting
> food on my table a very practical thing.

I completely agree. I'm not fortunate enough to be able to make a living
evangelizing free software either. (I work at a 99% MS shop. Used to be
100% until I got there, so I'm making inroads. :) )

However, the original question referred to how to archive a large amount
of data and split it into pieces for transferring to someone else. If
someone REQUESTS RAR specifically, and I have a business relationship
with them, I'll certainly oblige. However, if the format is unspecified,
as in this case it was, I would certainly choose to use free software to
do the job.

Alex Malinovich
Support Free Software, delete your Windows partition TODAY!
Encrypted mail preferred. You can get my public key from any of the
pgp.net keyservers. Key ID: A6D24837

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: