OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [office] RE: Directories in Zip packages

The problem of course is that the directory case is not defined in the APPNOTE at all, and presumably having file directories is a version 2.0 feature, and that is not specified in the version needed to extract, unless we can presume that is latent in the defaulting to MS-DOS/OS-2 whatnot.  Why would we require knowledge of a specific platform file-system convention in order to make cross-platform, interoperable ODF packages.  Does that mean we are limited to valid path and file names from the MS-DOS/OS-2 systems?  

I find this ridiculous.  

One more thing:

I did also take a look using another machine that did not (and never will) have PKZip installed.

You'll recall that WinZip did not display anything that was not actually a file, but it did say that "Configurations2\images\Bitmaps\" was OK when I tested the .odt as a Zip.  Also, 7-zip recognized it as a directory and PKZip showed Bitmaps as a folder.

Well, when I rename helloworld-signature.odt to helloworld-signature.zip, and then I drill down into it using Windows Explorer (not WinZip and on a machine where PKZip has not been installed), I get Bitmaps as an 0-length file of unknown association.  (See the attached PNG image.) 

Here's that puppy in the main sequence of Zip entries:

0000 1520                             50 4b 03 04 0a 00 00            PK♥♦...
0000 1530 00 00 00 35 86 38 3d 00  00 00 00 00 00 00 00 00   ...5å8=.........
0000 1540 00 00 00 1f 00 00 00 43  6f 6e 66 69 67 75 72 61   ...▼...Configura
0000 1550 74 69 6f 6e 73 32 2f 69  6d 61 67 65 73 2f 42 69   tions2/images/Bi
0000 1560 74 6d 61 70 73 2f                                  tmaps/

which does not seem any different than anything else, and here is the central directory entry:

0000 56a0             50 4b 01 02  0a 00 0a 00 00 00 00 00       PK☺☻........
0000 56b0 35 86 38 3d 00 00 00 00  00 00 00 00 00 00 00 00   5å8=............
0000 56c0 1f 00 00 00 00 00 00 00  00 00 00 00 00 00 29 15   ▼.............)§
0000 56d0 00 00 43 6f 6e 66 69 67  75 72 61 74 69 6f 6e 73   ..Configurations
0000 56e0 32 2f 69 6d 61 67 65 73  2f 42 69 74 6d 61 70 73   2/images/Bitmaps
0000 56f0 2f                                                 /

I see nothing here that would account for that except for a bug in how the shell decides not to make folders when there are no contents (notice in the image that Windows does not recognize the other empty folder entries, but this one seems to have confused things, maybe by being one "/" too far).

 - Dennis

I am really annoyed that PKZip stole the Zip association from Windows and the uninstall simply left there being no Zip association at all.  I will have to do a blankety-blank system restore to get it back.  Oh, goody.  
-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
Sent: Sunday, September 26, 2010 16:46
To: dennis.hamilton@acm.org; 'David LeBlanc'; office@lists.oasis-open.org
Cc: Cornelis Frank
Subject: RE: [office] RE: Directories in Zip packages


>2. There is no reason that ODF 1.2 ever needs such things in a package,
>since the manifest is independent of that stuff.

Well, perhaps no "need", but if it's allowed...it can be in there...

>3. It is not possible to sign a directory/folder entry in the Zip because
>there is nothing to sign. 

Actually, the same goes for the 0-size file, even an empty file can be signed :-)

> There is no data in such an entry and there should be no way to insert data
> in such an entry without it being a file instead of a folder

It is possible to craft a zip like that, although trying to unzip this could fail.
But who knows, perhaps some strange bug could be exploited because it is
not expected behavior.

>Oddly enough, the 0-length file Configurations2\accelerator\current.xml
>*has* data, and it is compressed, but the uncompressed size is 0.  Fancy

Since the storage method is deflate, not stored, it could perhaps be some
deflate header ?


To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]