HTTP transfer errors

Don,

A number of versions of WinRAR are known to be buggy. Over the years I've had a lot of problems unpacking what turned out to be *perfectly* good archives.

May I suggest you get a copy of 7-zip - which handles RAR very well

- and try it on the suspect archives.

George

Well, that seems to be the case with (at least some) of the examples I've attempted. E.g., unrar it once and it complains. Unrar THE SAME FILE a second time, and it doesn't. Third attempt might complain, again, etc.

As if some variable was being used uninitialized (and "happened" to end up with a "convenient" value one time the application loaded and an *inconvenient* one, the next).

However, I could also attribute that to (possibly) flakey hardware.

While most of my "multiple copies of same download" files appear to be identical, I did notice one instance where a single bit was altered (0x9? -> 0xB?). I think we've agreed that HTTP shouldn't let that happen.

So, either there's something flakey with the disk system (storage

*or* retrieval) *or* with the *processing* system (since WinRAR is out of the picture in this "COMPare" operation).

Yes, David (?) made a similar suggestion. It is installed on one of the other machines, here (not "exposed). But, the act of copying the suspect files to that other machine introduces another variable...

I should also download a more recent version of WinRAR as mine is from ~2000 (I've only had one client use this format previously so have not had need to keep the tool up-to-date).

Unfortunately, I'm in the middle of a bit of demo work around the house and getting out of that clutter is a prime concern for me, now. So, I haven't had time to analyze this methodically. I'd hate to get stuck jumping to conclusions and replacing things that don't need replacement (e.g., sort of like troubleshooting a dead car battery... replacing battery only to discover diodes in alternator are fried)

I don't know if that would help ... I haven't kept up with it.

The last really stable version I am aware of was 2.9something ... which is way old. I stopped even trying to use WinRAR around 3.6x because just about every version I tried from 3.0 to 3.6something had serious bugs: everything from crashing to not being able to read older versions' archives to not even reading same version archives.

7-zip handles about 30 archive formats (everything I care about and more). Once I found it, I never looked back.

George

I haven't had a *need* to keep up with it. :-(

I am always amused at these folks expecting me to "keep current" with *their* product -- as if *their* product was the only thing I had to worry about! Sheesh!

In the PC (windows) world, I tend to use zip. In the UN*X world, bz2 or gz. RAR was an oddball to me when a client "forced" me to unpack an archive of that form. I only acquired 7-zip when I was "forced" to unpack a 7z file.

I am pretty much convinced that my problem is *not* in the decompressor. I *copied* a "good" file (i.e., winrar "test"ed it as "good" on at least one occasion) to a USB drive for transport to another machine (*this* machine has no direct connection to the rest of my network). At that other machine, WinRAR complained of a CRC error. I made a note of the "content file" (for want of a better name) that the error was encountered in. I then tested the archive with 7zip and it complained (in the same "content file").

I copied this same file *again* via the known good USB drive. The second attempt resulted in a *good* result from both WinRAR *and* 7-zip.

So, either something is wacky in the OS on this machine *or* flakey hardware.

Given that I don't see any disk related errors reported in the system error log, I have to assume the problem is not related to the disk system itself.

Now where did I leave my Engineer's hammer...?

Actually, I think it's just the author relying upon the "you may not reverse-engineer the compression format" notice in the EULA being enforceable (which is debatable).

Plus: why bother? There are better compression algorithms out there. The format only matters insofar as other people use it, and you can get free decoders.

This piqued my curiosity... I was *sure* I had seen a "rar" in the pkgsrc repository!

So, I just took a peek. Yes, there's one there. But, it's a *binary* port ("Sure, I'm going to let some foreign executable run on this machine... *just* to give me another compressor? I don't think so...")

Yes, I noticed the unrar in pkgsrc is a source port. "OK, you can execute. So, we can *decompress* your format, we just won't *use* it!" :-/

Can you spell GIF?

(I'm sure *that* piece of IP made them BILLION$! -- Not!)

Or, use *zip* (also free).

Hi Don, since I took 7zip on board of my wintel-tv-set I have stopped thinking compression etc. It just does everything I ever needed so far (which is not that much perhaps, I am not doing real work on the tv-set). It does all thinkable formats (I had to untar something some time ago and searching for a tool I landed on 7zip).

Dimiter

OTOH, it's pretty clear that the WinRAR's author would prefer people to use it without paying than to stop using it altogether.

It goes to the trouble of checking how long it has been installed and points out that you are supposed to have paid for it by now, then goes on to function normally rather than disabling features or just quitting.

Which isn't really surprising, given that the only thing WinRAR has going for it is its installed base.

Microsoft used to take a similar approach (although they weren't quite so blatant about it) with Windows, back when it had competitors (in fact, they still do in emerging markets). If there's anything they dislike more than piracy, it's competition.

Yes, I have it on one of my machines. But, I prefer using command line tools for compressors. E.g., my build process typically has a "make archive" that goes through and bundles up everything for me so I can burn a CD, etc.

Command line tools are script-able. I don't know how to do similar things with "GUI tools" (e.g., can you *type* "7zip foo.c foo.s lib.l datasheet.pdf > archive.7z"?).

In my case, *de*compressing tends to be a one-time thing. E.g., take that archive and unpack it into a working directory. It's not like I am decompressing each time I "make" something.

(I guess I live with too much of the UN*X mentality :< )

7zip actually does have command line capability, though I haven't played with it any. If I recall, it's implemented as a separate executable linked to the same DLLs.

--
Rob Gaddi, Highland Technology
Email address is currently out of order

So, this is something that must be (explicitly) "added" to these tools? I.e., there isn't some inherent mechanism for invoking them from a command line? (yes, I recognize that I can *invoke* these from a command prompt but am more concerned with *using* them as such -- i.e., "driving" them with arguments)

The various compressors and decompressors are implemented in dlls. 7zip has three front-ends - a gui file-manager, an explorer plugin, and a command-line version. All are equally supported - the command-line tool is also available for Linux. So it's not a case of having some command line arguments for the gui program as an afterthought - it is a proper command line front-end.

I agree it seems that way. But that just makes the WinRAR authors somewhat dishonest too - if they consider their software "donationware", then they should say so.

Microsoft /were/ blatant about it:

"And as long as they're going to steal it, we want them to steal ours. They'll get sort of addicted, and then we'll somehow figure out how to collect sometime in the next decade."

Sorry, David, my question wasn't clear enough :<

I meant it in a more "generic" sense.

E.g., can I take *any* GUI application that runs under Windows and "drive it" from a command line (within reason)?

[i.e., my comment is not intended to be 7zip-specific]

Only in the rarest of cases. There are tools you can use to, for all intents and purposes, simulate mouse clicks to any program and try to drive it that way, but trying to accomplish anything that way is a crude approximation of hell itself.

--
Rob Gaddi, Highland Technology
Email address is currently out of order

Understood. I recall MS touting the concept of "automation" (talk about a misuse of a word!) which, I thought, was intended to allow these things to "control each other" through a published/exported "standard" interface.

If so, I thought it might have "command line counterparts".

But, as with much of MS's (ahem) "innovation", it often fails to fulfill its promises :>

Just an update data point...

After repeatedly moving big files and hoping for failures, I managed to locate several cases in which I would have two "copies" of a file -- one working, the other, not.

In each case, bytewise compares would turn up a single error. Always of the form XX1XXXXXb vs XX0XXXXXb.

Unfortunately, I wasn't diligent enough to notice *where* in the files these single errors were occuring (though I doubt it would have been much help to me since I have no way of knowing what the memory mapping in effect at that instant might have been!)

So, the obvious was to swap out the memory. That, of course, being an exercise in finding two "pink with yellow polka dot" DIMMs in a box of ~100 such parts (I really should organize my spare memory but fear that would be a wee bit *too* anal retentive!).

SO FAR, things seem to be working (of course, that could also be because the machine has cooled down, etc. from being off during my "update").

Curiously, the machine balked at the 1G ECC DIMMs I initially tried to install (in place of 2x512M). Every machine seems to have its own set of requirements. We'll see how this fares over the next few days...

No. That would work roughly as well as you can drive a car by throwing baseballs at the pedals and steering wheel.

You can start all Windows GUI applications from a command line, and most will accept a document name as an argument, but that's about where it ends. That gets really irksome when the program in question is, e.g., an IDE, and this limitation keeps you from using it to run batch builds of the projects defined in it.