Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2008-09

[RFC] Modification to packages/paszlib/src/zipper.pp

6 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Brad Campbell

With reference to this thread..
http://www.nabble.com/FPC-Zip-library-td15145102.html

and the resulting bug entry..
http://bugs.freepascal.org/view.php?id=10787

I had a similar requirement, so I went and had a crack at patching zipper.pas.

It does precisely what _I_ want it to do, but it's not the cleanest of hacks and I wonder if there is a better way to do it?

I post it here for comment anyway.

In short rather than call ZipFiles(), I now call ZipSomeFiles(). I can then replace the path each file will appear to have inside the zip file with SetFilePath() prior to calling ZipAllFiles() to create the zipfile.

I was thinking perhaps it might be better to attach an ansistring to each stringlist.object entry with a new path prior to calling ZipFiles() instead, but I thought I'd solicit comment first.

Regards,
Brad

Dolphins are so intelligent that within a few weeks they can train Americans to stand at the edge of the pool and throw them fish.

Reply by email

Michael Van Canneyt
to Brad Campbell
Brad Campbell wrote 10 lines
With reference to this thread.. http://www.nabble.com/FPC-Zip-library-td15145102.html and the resulting bug entry.. http://bugs.freepascal.org/view.php?id=10787 I had a similar requirement, so I went and had a crack at patching zipper.pas. It does precisely what _I_ want it to do, but it's not the cleanest of hacks and I wonder if there is a better way to do it?

The proper way is to create a new collection item

  TZipFileEntry = Class(TcollectionItem)
    ArchiveFileName : String;
    DiskFileName : String;
    FStream : TStream;
  end;
  TZipFileEntries = Class(TCollection)
  end;

And add an overloaded call

  ZipFiles(AFileName : String; Files : TZipFileEntries);
Which calculates ArchiveFileName from DiskFileName if ArchiveFileName is empty,
and which uses FStream if it is set instead of DiskFileName;

This can then be used to solve both the name inside the zip file as well as allowing it to work with streams (another request). The current call should then simply rework the stringlist to a TZipFileEntries collection, and call the overloaded version.

I'll have a stab at it this afternoon. Shouldn't be long to do.

Michael.

Reply by email

Michael Van Canneyt
to Michael Van Canneyt
Michael Van Canneyt wrote 29 lines
On Sun, 28 Sep 2008, Brad Campbell wrote: > With reference to this thread.. > http://www.nabble.com/FPC-Zip-library-td15145102.html > > and the resulting bug entry.. > http://bugs.freepascal.org/view.php?id=10787 > > I had a similar requirement, so I went and had a crack at patching zipper.pas. > > It does precisely what _I_ want it to do, but it's not the cleanest of hacks > and I wonder if there is a better way to do it? The proper way is to create a new collection item TZipFileEntry = Class(TcollectionItem) ArchiveFileName : String; DiskFileName : String; FStream : TStream; end; TZipFileEntries = Class(TCollection) end; And add an overloaded call ZipFiles(AFileName : String; Files : TZipFileEntries);

Implemented as proposed (rev. 11833).

I updated TUnZipper so it works with TZipFileEntry as well.

It is now also possible to provide the input through streams. (size is needed, so not every stream can be used).

Michael.

Reply by email

Brad Campbell
to Michael Van Canneyt
Michael Van Canneyt wrote 6 lines
Implemented as proposed (rev. 11833). I updated TUnZipper so it works with TZipFileEntry as well. It is now also possible to provide the input through streams. (size is needed, so not every stream can be used).

Absolutely fantastic. The stream option also saves me writing out a temporary file to disk to include it in the zip file. Thanks very much Michael!

I don't suppose this is likely to make it into the FIXES branch by any chance? (Not that it's a problem, I'll just leave zipper.pp in my local source tree)

Regards,
Brad

Dolphins are so intelligent that within a few weeks they can train Americans to stand at the edge of the pool and throw them fish.

Reply by email

Michael Van Canneyt
to Brad Campbell
Brad Campbell wrote 14 lines
Michael Van Canneyt wrote: > Implemented as proposed (rev. 11833). > I updated TUnZipper so it works with TZipFileEntry as well. > > It is now also possible to provide the input through streams. (size is > needed, so > not every stream can be used). Absolutely fantastic. The stream option also saves me writing out a temporary file to disk to include it in the zip file. Thanks very much Michael! I don't suppose this is likely to make it into the FIXES branch by any chance? (Not that it's a problem, I'll just leave zipper.pp in my local source tree)

It's currently not quite clear if the fixes branch is going to be used for the next release. In case it will be used for the next release, I'll make sure it ends up there.

Michael.

Reply by email

Burkhard Carstens
to Michael Van Canneyt
Michael Van Canneyt wrote 20 lines
On Tue, 30 Sep 2008, Brad Campbell wrote: > Michael Van Canneyt wrote: > > Implemented as proposed (rev. 11833). > > I updated TUnZipper so it works with TZipFileEntry as well. > > > > It is now also possible to provide the input through streams. > > (size is needed, so > > not every stream can be used). > > Absolutely fantastic. The stream option also saves me writing out a > temporary file to disk to include it in the zip file. Thanks very > much Michael! > > I don't suppose this is likely to make it into the FIXES branch by > any chance? (Not that it's a problem, I'll just leave zipper.pp in > my local source tree) It's currently not quite clear if the fixes branch is going to be used for the next release. In case it will be used for the next release, I'll make sure it ends up there.

I think many people use the fixes_2_2 branch because trunk is "too hot" but they need some of the 2.2.2 bugs fixed. So IMO it's good to merge non intrusive enhancements like this, regardless if the next release will be 2.2.4 or 2.4.0.

regards
Burkhard

Reply by email