ripley@tubopal.UUCP (Hans-Ch. Eckert) (01/08/90)
In article <CMM.0.88.631382411.cmm1@cunixa.cc.columbia.edu> cmm1@CUNIXA.CC.COLUMBIA.EDU (Christopher M Mauritz) writes:
]I've heard that ARC 6.0 is available for the ST. Where is it? Is it
]any good? Is it faster than 5.21? Enquiring minds want to know. [...]
It's just been posted to comp.binaries.atari.st
I tried it and I liked it. There are some things to complain on, though...
.complaining on
When I got arc 5.12 I've read that new compression methods will be
listed as "unknown" and can't be handled otherwise (naturally)... What I get
instead is a message "This version of arc can't handle file fubar.xyz. I
think you need a newer version of arc."... Not that this message is wrong or
shouldn't be printed, but WHY DOESN'T ARC CONTINUE TO DO ITS WORK BUT
IMMEDIATELY STOPS INSTEAD? If I do "arc v fubar.arc" and fubar contains
files which are squashed, I want arc to show me the contents of the
archive-file. If I do "arc x fubar.arc" I want arc to skip these
files such as "fubar.xyz - unknown compression method. Skipped.".
What I don't want arc to do is to abort the whole task.
This has been done by transitioning from arc 5.12 to wunderful(?) arc 5.21
with its squashing algorithm. This fault has been repeated on arc 5.21,
which can now be seen when listing an arc 6.xx archive which contains
sub-directories. Sigh.
.complaining off
Another one, which is more of a *real* (and heavy) bug:
Arc lost it's capability of dealing with overlong filenames.
That is, when I read news and save one or another article (under *NIX)
I sometimes use a name which doesn't fit into this nasty 8 char name
and 3 char extension -scheme. When I arc the saved articles afterwards,
arc puts them into the archive. When I list this archive with arc 5.12
the output format is mangled, but nothing else. Even with arc 5.21...
I have a Turbo-C port of arc (called tcarc), which has trouble in
displaying these entries... This doesn't matter too much, although it's
quite ugly.
When I list one of these archives with the recently posted arc 6.02,
it kind of crashes. It takes overlong time (far too much!), then it
displays entry corrupted, skipping xxx bytes messages !! The remaining
file-entries get displayed. On the last output-page with all those nifty
statistics, there are really weird numbers ! (How does an archive of
~200KB consisit of over 5 MB of data which leads to negative amount of
diskspace left on the drive the archive resides on ?)
This behaviour has been tested on at least 5 archives which contained
files with overlong names. It's highly repeatable, and if you often arc
on *NIX and often have overlong names, you'll often get annoyed with
this blatant bug !
Please, fix it asap !
Greetings,
RIPLEY
--
Greetings from RIPLEY | UUCP: ripley@tubopal.UUCP (ripley@opal.cs.tu-berlin.de)
Hans-Christian Eckert | ...!unido!tub!opal!ripley (Europe)
D-1000 Berlin 30 | ...!pyramid!tub!opal!ripley (World)
Regensburger Str. 2 | BITNET: ripley%tubopal@DB0TUI11.BITNET (saves $$$)hyc@math.lsa.umich.edu (Howard Chu) (01/12/90)
In article <814@opal.tubopal.UUCP> ripley@tubopal.UUCP (Hans-Ch. Eckert) writes: >IMMEDIATELY STOPS INSTEAD? If I do "arc v fubar.arc" and fubar contains >files which are squashed, I want arc to show me the contents of the >archive-file. If I do "arc x fubar.arc" I want arc to skip these >files such as "fubar.xyz - unknown compression method. Skipped.". >What I don't want arc to do is to abort the whole task. > >This has been done by transitioning from arc 5.12 to wunderful(?) arc 5.21 >with its squashing algorithm. This fault has been repeated on arc 5.21, >which can now be seen when listing an arc 6.xx archive which contains >sub-directories. Sigh. > That does seem to be a problem that the docs don't point to. Dunno why they did things that way... I'd fix it, but don't have the 6.02 sources. (Deep sigh. }-) >.complaining off > >Another one, which is more of a *real* (and heavy) bug: >Arc lost it's capability of dealing with overlong filenames. Well, it was pretty non-standard anyway, and the main idea was to maintain compatibility with the PC version of ARC. (But it was certainly trivial to allow for arbitrarily long names, really.) The official "fix" I posted for the Unix side was to make it automatically truncate long names to fit into 12 characters. So it goes. You could easily add back in the code to allow for long names though. Dunno what you'd do with them when you try to extract them, but at least it wouldn't choke... -- Howard >Greetings, > RIPLEY -- -=- PrayerMail: Send 100Mbits to holyghost@father.son[127.0.0.1] and You Too can have a Personal Electronic Relationship with God!
nelson@kodak.UUCP (Bruce Nelson) (01/12/90)
Another bug I found in arc 6.02 is the definition of the "p" command:
p = copy files from archive to standard output
Arc 6.02 prints the file to the line printer. Previous versions (5.21 and
earlier) outputted the file to the screen or could be redirected via
the ">" operator.
If anyone near Phoneix could point this out to Darin Wayrynen on his bbs
(Next Gen BBS (602) 938-8288) I'd appreciate it.
Bruce Nelsonroeder@sbsvax.UUCP (Edgar Roeder) (01/13/90)
In article <10615@stag.math.lsa.umich.edu>, hyc@math.lsa.umich.edu (Howard Chu) writes: > the Unix side was to make it automatically truncate long names to fit into > 12 characters. So it goes. You could easily add back in the code to allow > for long names though. Dunno what you'd do with them when you try to extract > them, but at least it wouldn't choke... I know it: You can create unique filenames during extraction (example: longname-1 is changed to longname.-1, longname-2 into longname.-2 instead of both being mapped into longname), even if the original names on the unix-machine aren't unique up to the first 8 chars + 3 chars extension. For example if i have extracted sources from usenet with unshar on the unix machine, i normally don't want to rename dozens of files. Instead i am archiving the whole directory as it is with zoo. At home when i am extracting those files, zoo tries to create unique TOS-filenames or asks me wether i want to rename it. What i also like is that with zoo i can use arbitrary long names on the parameter line to specify the archive file. Arc simply cuts after the 8th character. Zoo would try to open the file even if the name does not constitute a valid file name on TOS. Now you could ask: why do you want this? - Since i am using '/' instead of '\' as directory delimiter in my shell. Zoo can unpack '../archive', but arc will only try '../archi' (which fails) and i have to enter '..\\archive'. Why does Arc make so much assumptions about the environment in which it will be run ? This must be code which is commented out in a unix version. Why not just use the same source anywhere ? Why those artificial restrictions ? > -- Howard - Edgar -- Mail: Edgar R\"oder E-Mail: roeder@cs.uni-sb.de Liesbet-Dill-Stra\ss e 3 D-6602 Dudweiler -o- -o- W-Germany ^ Phone: 06897/74643 '---'