User (Old forums)MemberJuly 12, 2005 at 11:53 amPost count: 23064
The following code snippet returns the read stream from a zipped file:
ZipArchive zipArchive = this._ZipArchiveForPath(mZipFileName); // open ZipArchive from StreamFile
AbstractFile zipEntryFile = zipArchive.GetFile(mZipEntryName);
This code is part of a transparent file system layer which supports compression. Because of its transparency to the user, when the user closes the given stream, the underlying ZipArchive should be closed too. Is there any way to accomplish this with Xceed Zip for .NET? This would heavily influence our decision of whether or not to switch to Xceed.
Thanks for your consideration,
Imported from legacy forums. Posted by cE (had 3341 views)User (Old forums)MemberJuly 12, 2005 at 1:36 pmPost count: 23064
I confirm you that upon closing the last open stream on a ZippedFile, the target file that was passed to the ZipArchive’s ctor is rebuilt.
You can control when it is recreated by calling BeginUpdate/EndUpdate on the ZipArchive.
I suggest you read <a href=”http://blogs.xceedsoft.com/plantem/PermaLink.aspx?guid=a4ea2021-91ce-482d-a54d-b3dd04f18f2d”>this post of mine</a>.
Imported from legacy forums. Posted by Martin (had 231 views)User (Old forums)MemberJuly 13, 2005 at 3:49 amPost count: 23064
Thanks for your reply. I read your blog posting you linked to, but I cannot quite relate the described scenario to what my problem is. Perhaps I should explain more clearly what the complication is in my case:
– The user gets the read stream returned from a ZippedFile:
AbstractFile zipEntryFile = zipArchive.GetFile(mZipEntryName); // (1)
Stream returnedStream = zipEntryFile.OpenRead(); // (2)
– The user reads data from the stream and then calls returnedStream.Close().
– returnedStream is then correctly reported to be closed/disposed, _but_
– When closely scrutinising all file handles (with ProcessExplorer), one can clearly see that the handle created for the zip file in (2) is not closed. This means, e.g., that when subsequently trying to access the ZipArchive’s underlying file (the one given at (1)) for writing, a System.IO.IOException occurs, informing me that `The process cannot access the file […] because it is being used by another process.’
I have compared this behaviour to another zip file access library, namely SharpZipLib (version 0.83), and this one `correctly’ closes the file handle after the read stream has been closed.
Perhaps you could enlighten me whether I not fully understand the problem, or how this specific situation can be rectified using Xceed Zip.
Thanks for your consideration,
Imported from legacy forums. Posted by cE (had 226 views)User (Old forums)MemberJuly 13, 2005 at 7:43 amPost count: 23064
Oh, ok, that shouldn’t be! Once the last stream returned by ZippedFile.OpenRead is explicitly closed, no stream should be open on the source zip file.
Send an email to email@example.com to get assigned a case number about this. Just point to this post. It will end-up in my hands, and I’ll try to reproduce and take a closer look at what could be the problem.
Imported from legacy forums. Posted by Martin (had 4148 views)
- You must be logged in to reply to this topic.