🚀 go-pugleaf

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                     	       	 '---'