Re (3): [Oberon] Homework on ZipTool
peter_easthope at gulfnet.sd64.bc.ca
peter_easthope at gulfnet.sd64.bc.ca
Wed Sep 4 21:59:01 CEST 2002
Pat, Pieter & others,
p> ... perused the source code. ... I'm not an expert.
Most of us are in the same boat. Thanks for the help.
p> 1) ZipTool.(Directory | Extract | ExtractAll) do not
require a .Zip extension.
Good. How is this shown properly in the Zip.Tool?
*.Tool texts are a quasi-EBNF which I don't
understand well. Here is a speculation.
ZipTool.Directory [\d | \D] <Zipfile>.Zip ~
ZipTool.Directory [\d | \D] <Zipfile> ~ .Zip suffix optional.
ZipTool.Directory [\d | \D] ^
p> 2) ... DefaultStrategy* = 0; (** for normal data **)
Is the default, string matching only and no
Huffman coding?
p> 3) I don't understand the question. AddFile is for programs
and Add is for users.
Why shouldn't they both be exported?
Agreed. I plead absent mindedness.
p> 4) non-consistent file name should give error and continue
I take by this you may have consistent and non-consistent entries in the
same zipfile
and you would like to extract the consistent ones. Correct?
Yes.
p> Any reason you couldn't use "=>" to give it a consistent file name?
OK for Extract.
How should ExtractAll operate when the
archive contains many files and only a few
have exceptional names?
At least it should extract all the files with
conventional names and report the non
-conventional names. The user could then
rename or extract to an appropriate filesystem.
More ambitiously, ExtractAll might accept the
renaming arguments but this would incur
significant checking in the case of an archive
containing many files with only a few being
renamed. Probably not justified.
Regards Peter
Peter Easthope http://carnot.pathology.ubc.ca/
More information about the Oberon
mailing list