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