[delphizip] Re: Another bug in Unzdll.dll (ver160) and workaround
- From: "Roger Aelbrecht" <roger.aelbrecht@xxxxxxxxxx>
- To: <delphizip@xxxxxxxxxxxxx>
- Date: Tue, 19 Mar 2002 15:29:30 +0100
> -----Original Message-----
> From: delphizip-bounce@xxxxxxxxxxxxx
> [mailto:delphizip-bounce@xxxxxxxxxxxxx]On Behalf Of Angus Johnson
> Sent: Wednesday, March 06, 2002 8:00 PM
> To: delphizip@xxxxxxxxxxxxx
> Subject: [delphizip] Another bug in Unzdll.dll (ver160) and workaround
>
> Other issues I've spotted with the vers160 dlls:
>
>
> Angus Johnson
As promised I did some digging to find looking for answers:
for item 1.
> 1. when adding Foldernames to FileSpecList, a trailing slash is required
> to indicate they are folders.
I have to disagree on that, or I am missing something.
Entries in FileSpecList will be processed in ZipDllExec2 in dllmain.c
this calls zipmain that in its turn calls 'Wild' in Win32zip.c
Here we have the statements:
if ( !pG->recurse && !pG->ArchiveFiles ) {
if ( !LSSTAT( GetFullPath( pG, w ), &s ) ) /* file exists ? */
return procname( w, false, pG );
return ZEN_MISS02; /* woops, no wildcards where is the file! */
}
If GetFullPath returns a valid file or folder name the function 'procname'
will add the trailing slash for a folder.
I think we should ignore the comment in front of procname that says:
" * We will only arrive here if we do a Freshen or Delete."
In all test I have done when a folder name with a valid path is added the
dll
will append a trailing slash.
> 2. ??bug - if filenames are stored in OEM format the dll will extract
but
> not delete them.
I think we have a real bug here. The Unzip dll has code to do an OEM to ISO
conversion the zip dll is missing that entirely
Extract uses un zip dll so conversion is done
Delete uses zip dll so no conversion is done and the file spec is not
recognised,
during my tests I always seemed to end up with a ruined archive due to some
incomplete deletion.
I will try to find a solution for the zip dll and if possible use the same
"universal" code as provided in the unzip dll.
I will inform you about any progress.
> 3. cancelling an add/delete operation corrupts the zip file. A
workaround
> requires saving a copy of the file before these operations.
I think Eric's reply has been clearly about that problem.
However I took the liberty of looking into the TZip component and there is a
difference with allowing cancel to be returned by Tzip versus
TZipMaster/TZipbuilder.
In TZipMaster/TZipbuiler only one place can return Cancel from Zcallback and
that is in response to an action 8.
In TZip Cancel is allowed in Action 8, 9 and 10 especially this last one
could
be dangerous.
Regards
--
Roger Aelbrecht
http://web.wanadoo.be/driehoeksw
Other related posts:
