[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:
--snip--
> 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.

--snip--
> 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.

--snip--
> (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: