In some cases, it is not possible to get the Position of a stream, let's say, on a write-only output stream like ASP.NET's Response.OutputStream
, or on a different write-only stream provided as the destination for the zip by the application. In this case, programmers can use this counting stream to count the bytes read or written.
Consider the scenario of an application that saves a self-extracting archive (SFX), that uses a custom SFX stub.
Saving to a filesystem file, the application would open the filesystem file (getting a FileStream
), save the custom sfx stub into it, and then call ZipFile.Save()
, specifying the same FileStream. ZipFile.Save()
does the right thing for the zipentry offsets, by inquiring the Position of the FileStream
before writing any data, and then adding that initial offset into any ZipEntry offsets in the zip directory. Everything works fine.
Now suppose the application is an ASPNET application and it saves directly to Response.OutputStream
. It's not possible for DotNetZip to inquire the Position
, so the offsets for the SFX will be wrong.
The workaround is for the application to use this class to wrap HttpResponse.OutputStream
, then write the SFX stub and the ZipFile into that wrapper stream. Because ZipFile.Save()
can inquire the Position
, it will then do the right thing with the offsets.