[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice
Subject: Re: KDE does not recognice KWord docs
From: David Faure <dfaure () klaralvdalens-datakonsult ! se>
Date: 2003-10-08 20:12:55
[Download RAW message or body]
On Wednesday 08 October 2003 21:01, Nicolas Goutte wrote:
> > The extra field with the ID "0x000d" includes times and uid/gid indeed.
>
> Yes, but there are at least 3 Unix extra fields. Id 0x000d is only the PKWARE
> one.
>
> I was talking about the *new* InfoZIP one (id 0x7855). It has only uid/gid as
> time is given by the extra field with id 0x5455
I don't understand your point here (we don't use this infozip extra field... so?)
Seriously, who needs uid/gid in a zip file? If I extract a zip file myself,
I want all the files to belong to me - not to whoever is id=42 on my system
just because the person who made the ZIP file had id=42...
> > But that's not the extra field we're using anyway. We're using the one with
> > the ID "0x5455" ("UT"), which is called "extended timestamp" in the spec,
> > and which isn't defined by pkware. I guess Hoelger found its definition
> > somewhere else. It only includes mtime/ctime/atime apparently.
>
> The doc is in the InfoZIP tools. You simply need to download the source of zip
> or of unzip. It is a file named proginfo/extra.fld.
>
> InfoZIP's zip does not use the extended timestamp alone, unlike KZIp. Zip uses
> it always with one of the OS extra fields, with Unix with the new Unix extra
> field (id 0x7855.) (However this exact problem can probably wait until KDE
> 4.)
This file format is flexible - one can choose which information he puts in the
extra fields. So I don't see what's wrong with what we do now (we put the
information we need, and we parse 2 or 3 different kinds of headers that
others might use), but I'm not objecting to changes there, of course.
> What we need are some sorts of personallities:
> - Zip under Unix
> - standard behaviour under VFAT (so old MS-DOS stuff but with long file names)
But why do we need the FAT mode, if everyone involved can read Unix zips?
I mean, when I use the "zip" command to create a zip file, and I send that file
around, everyone can read it, although the 'version' in the zip file says 3, "unix".
Can't OO read ZIP files with a "unix" version? Since this is what KZip has
been creating for some time, and the OO export filter alledgedly works, I guess
it works just fine...
> As for a future personality, this could be ZIP64 (or not allowing 64 bit
> extensions.) That too is something different from pure ExtraFields.
Right, so it should be a separate enum.
> As for having again the support of DOS/FAT, the problems are the details. As
> OS DOS/FAT, you have to convert again the permission to FAT permissions (not
> too difficult, as the code existed.)
>
> Also you cannot define a symlink with DOS/FAT OS. So you have to catch
> symlinks and issue them as Unix OS despite the WriteMode (or you simulate the
> bug of PKZIP on Unix and uses the 0x000d extra field but with OS DOS/FAT.)
I fail to see why we need to go to all that trouble.
> As written in one of my emails, for OO compatibility, we probably better stick
> to this classical mode to avoid any difference. (There will probably be buggy
> programs that will shoke at OS == Unix, either directly or because the extra
> fields are missing.)
You're assuming the worst - I'm suggesting to actually check if there's any
problem before "fixing" it.
> So if you like the interface that I am proposing, you can change KZIp (so you
> can change KOffice now) and I shall fill the missing details in the next days
> (if there is not again something delaying me.)
I have nothing against the additional modes to KZip, although I don't see the purpose,
but I'd really like that the various settings are kept in separate enums, that's much
more flexible. If you really want all the possibilities implemented, we'd have 3 enums,
one for what to put in the extra fields, one for the 'version' (i.e. unix vs fat modes,
including the filename and symlink issues), and one for zip64 in the future).
--
David Faure -- faure@kde.org, dfaure@klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions
____________________________________
koffice mailing list
koffice@mail.kde.org
To unsubscribe please visit:
http://mail.kde.org/mailman/listinfo/koffice
[prev in list] [next in list] [prev in thread] [next in thread]