[delphizip] Re: R: Re: Add - abort corrupts zip - a couple of alternatives
- From: "Russell Peters" <russellpeters@xxxxxxxxxxx>
- To: <delphizip@xxxxxxxxxxxxx>
- Date: Tue, 17 Sep 2002 17:44:24 +1000
It might be able to be made to cease adding/extracting after each file
unless a dll abort function is called - that is used to stop almost
instantly for unloading or destroying a thread.
I am testing a change for extracting specified files (a quick test reduced
number of filename matches to less than half). Hope to test more tomorrow.
Also the VCL's could do with testing first extract-spec for *.* and clearing
them to speed up extracts (make it do fast extract all).
- Russell Peters
----- Original Message -----
From: "Matteo Riso" <matteo@xxxxxxxxxxxx>
To: <delphizip@xxxxxxxxxxxxx>
Sent: Tuesday, September 17, 2002 8:11 AM
Subject: [delphizip] R: Re: Add - abort corrupts zip - a couple of
alternatives
>
> Checking for abort after each file compression seems to be a good idea.
>
> Matteo Riso
> www.zipgenius.it <http://www.zipgenius.it>
> Happy ZipGenius User #1
>
>
>
> -----Messaggio originale-----
> Da: delphizip-bounce@xxxxxxxxxxxxx
> [mailto:delphizip-bounce@xxxxxxxxxxxxx]Per conto di Russell Peters
> Inviato: lunedì 16 settembre 2002 23.25
> A: delphizip@xxxxxxxxxxxxx
> Oggetto: [delphizip] Re: Add - abort corrupts zip - a couple of
> alternatives
>
>
>
> The problem with appending is that in doing so overwrites the 'central'
> directory and message areas.
> If (a very big if) the abort is not caused by the compression of the
current
> file (say because it is taking way too long or will not fit) then checking
> for abort could be done after each file is compressed and then the zip
> finished as normal (but process no more files).
> I think I should be able to make it (via a new option) always use a
> temporary file, and I thought then if option set and TempDir set it could
> make temporary new file before copying to destination (needed if sending
to
> CD burner via packet software.
> I will have to think about it for a little while.
> - Russell Peters
> ----- Original Message -----
> From: "James Turner" <james.d.h.turner@xxxxxxxxxxxx>
> To: <delphizip@xxxxxxxxxxxxx>
> Sent: Monday, September 16, 2002 8:25 PM
> Subject: [delphizip] Re: Add - abort corrupts zip - a couple of
alternatives
>
>
> >
> > Simply appending files (rather than using a temp file) to speed things
up
> > seems sensible. If the DLL always aborted cleanly, there would not be a
> > problem so perhaps the judicious use of a try...finally would sort this
> out.
> > Or perhaps changing the action taken in response to the abort flag might
> be
> > in order. For instance, erasing the list of files to be added. This
would
> > only allow abort between files to take place but this would be better.
If
> > aborting within a file is to be allowed, perhaps this could be achieved
by
> > faking an end-of file response. If this were done, however, the file
> should
> > be renamed something like '$$$$...$$$' (i.e. replace all chars with
> dollars)
> > to indicate that it is invalid.
> >
> > Without delving into the DLL source code, I can't say if any of the
> > suggestions above are sensible or not, but I thought it might be worth
> > pointing out these possible alternatives.
> >
> > James Turner
> >
> > PS
> > Just had another (silly ???) idea. From memory, the CRC code is
calculated
> > from the source rather than the compressed data. In this case, would it
be
> > sensible, when replacing files, to calculate the CRC code for the new
> files
> > before addition. If the file hasn't changed there's not much point
adding
> > it. Of course, there are options to compare dates so perhaps this isn't
> > worth the effort. (If lengths are identical, then calc CRC. Change file
> date
> > in zip file if necessary.)
> >
> > -- just a thought.
> >
> >
> > ----- ORIGINAL MESSAGE ------
> >
> > I have located the problem - the dlls do not always use a temporary
file!
> > If it needs all of the original files it simply appends the new files
(so
> > can and does lead to corrupt files), this improves the speed when
dealing
> > large files.
> > There is some unused code that I think will try to repair the old file
but
> > it has been commented out.
> > The code is not very explicit (the append flag in zipmain is 'b' ).
> > Any way around this problem is at best a compromise but perhaps and
> AddSafe
> > option could be used to force it to always use a temporary file.
> > - Russell Peters
> >
> >
> >
> >
>
>
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.384 / Virus Database: 216 - Release Date: 21/08/2002
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.384 / Virus Database: 216 - Release Date: 21/08/2002
>
>
>
Other related posts:
