CompressionFinished Event?

Apr 17, 2009 at 3:38 AM

First, outstanding library!

However, I've noticed there's an event for Compressing and FileCompressionStarted. Is it possible to get a CompressionFinished or Finished event? I basically need to know when compression on a directory is finished so I can delete the original files the compressor just finished compressing, otherwise I'm noticing that the compression is taking place in one thread, while my program continues, thinking it can interact with the files that are being compressed and then crashing because of it. Or.. maybe I'm attacking this the wrong way, please let me know if I am.
Apr 17, 2009 at 9:35 AM
Edited Apr 17, 2009 at 9:44 AM

I thought CompressionFinished is not necessary, you can just place the code after each CompressSomething method call. The compression is performed in the same thread (by the way I included special example of multi-threaded compression in SevenZipTest). Did you actually get a crash? If you did, please post the exact exception mesaage and your code.
Anyway, I've implemented the CompressionFinished event. Check SVN ("Source Code").

Apr 17, 2009 at 9:06 PM
Edited Apr 17, 2009 at 9:08 PM

Here's what I'm encountering:


SevenZipCompressor oCompressor = new SevenZipCompressor();
AppDomain.CurrentDomain.BaseDirectory + "Save\\Temp", AppDomain.CurrentDomain.BaseDirectory + "Save\\" + "Save.7z", OutArchiveFormat.SevenZip);

// Remove temporary save files
Directory.Delete(Simulator.TempSaveGamePath, true);

What is happening however is that the line that compresses the directory returns very quickly and I know it can't possibly be compressing the full directory that quickly, so it must be creating an asynchronous compression process so as not to block my code which is fine, however it then moves on to delete the files it just compressed as part of a cleanup routine, that's where I get the error: 'The process cannot access the file 'File1.dat' because it is being used by another process.' Which makes sense because the compression library must still be doing it's job. This is why I needed a hook to detect the end of the compression process so I could perform my file cleanup stuff and not having processes stepping on each others toes. I see you've added the CompressionFinished event which is great, but I still am curious is there another way to do what I'm trying to do, I figured a Finished event was needed regardless, but maybe I'm wrong.

(I'm sorry if the code isn't formatting very well I'm not sure how best to format code on this site).

Thank you!



Apr 17, 2009 at 10:27 PM
I've tried the above code using CompressFiles and am running into the same issue, it does not happen unless the files are large enough that the compression takes a little while, if I try this excercise with small files (1k in size) it works fine and it cleans up the files, so I don't *think* it's my code, but I'm not positive either :) I just wanted to update you, is there any chance the library is leaving handles to files open or any kind of delay etc?

I'm just trying to get to the bottom of this.

Apr 17, 2009 at 10:33 PM
Okay last update for the time being, I'm positive my application isn't the culprit because if I remove the compression lines and test it with the same larger files, it works fine, it's only when I try to compress those that for some reason that compression routine is returning before it's released those file streams or something (I'm completely guessing) because then it messes up when my code tries to go and delete those files. Let me know if I can be of any further help!
Apr 18, 2009 at 4:32 AM
Conclusion, I managed to solve my problem better and more efficiently by doing everything in memory and then using CompressDictionaryStream() method, this works perfectly for me and there is no need to use file streams etc, just all around a better solution. I just wanted to let you know :)

Sorry about requesting that Finished event, although I think it's still worthwhile for somebody down the road.

Thanks again and keep up the great work!
Apr 18, 2009 at 8:03 AM
>oCompressor.CompressDirectory(AppDomain.CurrentDomain.BaseDirectory + "Save\\Temp", AppDomain.CurrentDomain.BaseDirectory + "Save\\" + "Save.7z", OutArchiveFormat.SevenZip);

This is weird, this line can't be compiled because in the recent version of my library you must write the other way:
oCompressor.ArchiveFormat = OutArchiveFormat.SevenZip;
oCompressor.CompressDirectory(AppDomain.CurrentDomain.BaseDirectory + "Save\\Temp", AppDomain.CurrentDomain.BaseDirectory + "Save\\" + "Save.7z");

The thing you wrote about in the first post is likely to be a bug in SevenZipCompressor, because no asynchronous compression process happens at all and all file streams should be closed in this method!
Try to do the following:

SevenZipCompressor oCompressor = new SevenZipCompressor(true);  //throw diagnostic exceptions
(...) //the same code

And see if you get any exceptions (you are definitely to catch some). The point is that SevenZipCompressor encounters the internal bug (independent of your code), doesn't compress all the files and doesn't close some file streams.
Thanks in advance, Vadim.
Sep 27, 2011 at 12:06 PM

Is there any update on this.....


I can confirm the issue above, when compressing, compressed files, it never seems to release the thread so any IO operations throw an IOexception.