[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: KDE does not recognice KWord docs
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2003-10-08 19:01:46
[Download RAW message or body]

On Wednesday 08 October 2003 18:56, David Faure wrote:
> On Wednesday 08 October 2003 16:45, Nicolas Goutte wrote:
> > Too bad, we both seem to have worked on the same stuff. :-(
>
> Hmm. I was afraid of that. That's why I said "I'll do it" when I started to
> work on it - I was afraid that nobody would fix it.... Anyway it didn't
> take long.
>
> > However, your solution still keep OS==3 (Unix) instead of OS==0
> > (DOS/FAT/...)
>
> Sure, since AFAICS the version number is independent from the extra field
> stuff.

That is exactly my critic. This is not alone about having an extra field or 
not (or which extra field), this about to have either the same as zip on Unix 
or the same as PKZIP on VFAT (which OO uses.) Your solution remains in the 
middle.

>
> > Also I do not find it right to define it as extra field yes/no,
> > especially that you seems limit it to the modification time. However if
> > KZip would have been complete, this would include the Unix uid/gid extra
> > field too.
>
> You're confusing two things.

No!

> 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

> 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.)

>
> Anyway - I didn't add a yes/no boolean, I added an enum, for this very
> reason. If we want to write out other stuff later, we can do so by adding a
> value to the enum - and internally, using whichever extra field allows us
> to model that data.

Sure, but you named it "ExtraField". However this is not only about extra 
fields.

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)

(The long filenames are just not to make it even more complex. For OO, it 
makes no difference, as OO's filenames are 8+3 anyway.)

So what I had in mind was some interface like:

enum WriteMode
{
	DefaultMode=0, // Currently: OS Unix, extended time stamp (future uid/gid)
	ClassicalMode=1, // As much as under DOS, but with long filenames
	LikeOOMode=ClassicalMode 
}

KZip::setWriteMode(WriteMode mode)

Perhaps it would be better to do like you did and give the default mode are a 
name too.

As for a future personality, this could be ZIP64 (or not allowing 64 bit 
extensions.) That too is something different from pure ExtraFields.

***

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.)

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.) 

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.)

Have a nice day!
____________________________________
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]