An outline proposal
bobjolliffe at gmail.com
Tue Oct 19 15:57:29 CEST 2010
On 19 October 2010 13:20, Dave Pawson <dave.pawson at gmail.com> wrote:
> One more Bob.
> On 19 October 2010 11:38, Bob Jolliffe <bobjolliffe at gmail.com> wrote:
>>>> 2.2 Any file hierarchy present when the package is created shall be
>>>> duplicated on extraction if requested.
>>> So this leads to the requirement that you can store a file hierarchy.
>> Again I would not straight away assume we are talking of a file
>> hierarchy. The contents of the package may have started off as files.
>> And may even be extracted to files. But is this necessarily so? I
>> would prefer to think of the zip as simply a container for streams.
> I think it important that if files are used, some hiearchy may be
> retained through the zip/unzip actions? Agreed we may not be
> dealing with files-on-disk, but if we are.... then I think this is
> No idea how to bring streams into that one!
Agreed. What is actually in the zipfile is:
[local file header 1]
[file data 1]
[data descriptor 1]
[local file header n]
[file data n]
[data descriptor n]
[archive decryption header]
[archive extra data record]
[zip64 end of central directory record]
[zip64 end of central directory locator]
[end of central directory record]
Where 'File data' has a filename field where the appnote specifies
that '/' is to be used a directory separator. Its interesting to note
that both the relative path and even the filename itself are in fact
optional (I hadn't realized the latter). I would be happy (if we were
writing a profile) to mandate that these should in fact be necessary
to facilitate the requirement you raise. Though its maybe worth
bearing in mind that there is actually no 'real' directory in the zip
which files reside in. They are just streams of data with names which
allow them to be potentially mapped into a filesystem in particular
ways. Named streams (like named pipes :-) )
BTW you had asked above for me to define 'central directory'. It's
there in the appnote.
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.
> sc34wg1study mailing list
> sc34wg1study at vse.cz
More information about the sc34wg1study