dbercel@sun.uucp (Danielle Bercel, MIS Systems Programming) (07/16/87)
Since we are all talking about compatibility between
PKARC and ARC, I just recalled another area of slight
incompatibility. The encryption option.
PKARC version 3.5 has implemented ARC's -g option to
encrypt a compressed file. I use this function for
my personal correspondence. Just as a small measure of
security.
When PKARC added this feature I tried it against one of
the ARC encoded files and found that it did not decrypt
it properly. After that small test I decided
against further testing since this was in the minority of
uses I put PKARC to.
In light of our current conversation, I just thought I'd
mention it. And, one other thing.
There have been a few messages about how horrible it
is for a new method to be introduced that is not
compatible with existing compression methods. I would
like to point out that when ARC was first introduced
it replaced a number of existing programs (nusq, usq, lupc,
etc.), and was incompatible with them.
Since PKARC seems to be gainning ground as the standard for
many BBSes, it would appear the the original ARC will
have to catch up or see their product go the way of
the products that they originally surmounted.
danielle
--
UUCP: {hplabs,decvax,}!sun!toto!{danielle,dbercel}
/-------------------------------------\
| Toto, I don't think this is Kansas. | -- Danielle Bercel
\-------------------------------------/ Sun Microsystems, Inc.tes@whuts.UUCP (STERKEL) (07/17/87)
In article <23599@sun.uucp>, dbercel@sun.uucp (Danielle Bercel, MIS Systems Programming) writes: > Since we are all talking about compatibility between > PKARC and ARC,...... > There have been a few messages about how horrible it > is for a new method to be introduced that is not > compatible with existing compression methods. I would > like to point out that when ARC was first introduced > it replaced a number of existing programs (nusq, usq, lupc, > etc.), and was incompatible with them. BUT, did SEA blithely declare compatibility, and *KEEP THE SAME EXTENSION* (.ARC), even in the face of obvious user confusion and angst? -- Terry Sterkel {clyde|harvard|cbosgd|allegra|ulysses|ihnp4}!whuts!tes [opinions are obviously only my own]
feg@clyde.ATT.COM (Forrest Gehrke) (07/17/87)
In article <23599@sun.uucp>, dbercel@sun.uucp (Danielle Bercel, MIS Systems Programming) writes: > Since we are all talking about compatibility between > PKARC and ARC, ................ > [deletions] > Since PKARC seems to be gaining ground as the standard for > many BBSes, it would appear the the original ARC will > have to catch up or see their product go the way of > the products that they originally surmounted. > As for example Computer Innovations ARCH.EXE, which incidentally used the extension .ARC I had many files to be re-archive after after SEA's archive program was released. Since PKARC is downward compatible with SEA, I haven't got that task this time. Forrest Gehrke
jvc@mirror.UUCP (07/20/87)
>BUT, did SEA blithely declare compatibility, and *KEEP THE SAME >EXTENSION* (.ARC), even in the face of obvious user confusion >and angst? > Terry Sterkel Yep. Try using ARC 3.* to unarchive a file archived by ARC 4.* or ARC 5.*. "Compressing" was added in version 4.0 making it impossible for ARC 3.0 to unarchive any files packed by this new technique. The extention of the archive, however, remained the same. Imagine the "obvious user confusion" that this caused; one couldn't use SEAware's ARC to unarchive archives archived by SEAware's ARC. As for changing the extention, this would only help in the short term because either SEAware will remain stuborn and their product will die or they'll wise up and add "unsquashing" ability to their product. If their product dies, then the extentions won't matter since PKARC can unarc ARC archives. If SEA adds unsquashing, then the different extentions will be ignored and people will use their favorite unarcer first and if that doesn't work they'll try the other unarcer (and if that doesn't work, they'll look for new versions of both programs [remember, ARC 3.0 couldn't unarchive ARC 4.0 archives]). So, changing extentions won't be a long term solution and in fact will probably cause more confusion. Maybe a solution would be to add a string to the archive that would indicate which program and what version created the archive. If each unarchiver would print this string if it discovered that it was unable to unarchive one or more files, then it would help the user to figure out what was wrong. However, if SEA won't add unsquashing then they won't add this feature either. jvc@mirror.tmc.com NOTE: it was mentioned somewhere in this group that PKARC had trouble with insufficient memory errors. I got email (apparently) from phil stating that this was indeed a bug in version 2.0. This bug was a result of the Lattice compiler and not with the code (I won't waste the time relaying the explanation of the bug because this bug doesn't appear to be in version 3.5. Contact phil directly if you want the explanation.)