Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!lll-lcc!lll-tis!ames!amdcad!sun!dbercel From: dbercel@sun.uucp (Danielle Bercel, MIS Systems Programming) Newsgroups: comp.sys.ibm.pc Subject: PKARC 3.5 -g option Message-ID: <23599@sun.uucp> Date: Wed, 15-Jul-87 23:47:24 EDT Article-I.D.: sun.23599 Posted: Wed Jul 15 23:47:24 1987 Date-Received: Sat, 18-Jul-87 05:48:03 EDT Reply-To: dbercel@sun.UUCP (Danielle Bercel, MIS Systems Programming) Distribution: na Organization: Sun Microsystems, Inc. - Mtn View, CA Lines: 37 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.