If the zip file corrupted or not a zip file, the file will keep be occupied by aspose zip and cannot be released

Aspose.ZIP Product Family
1

I’m developing with latest Aspose.zip in c# to handle zip entries.
But recently i met issue that the file will be occupied by aspose zip and cannot release the file. To quickly reproduce the issue, you can try with any file that is not a zip.
e.g, with code
try
{
using (var lzip = new LzipArchive(“C:\demo.eml”))//is not a zip, actually an email file, but i believe other type can also reproduce the issue
{
lzip.Extract(“C:\tempFolder”);
}
}
catch (Exception ex)
{
Thread.Sleep(3000);
File.Delete(“C:\demo.eml”);
}
The file cannot be deleted and it seems even using state used, aspose zip still keep the wrong file and not release it.
Please take a further look to this.
Thanks

2

@xieming95at163.com

It sounds like you’re encountering an issue where the Aspose.Zip library is not releasing a file handle when trying to extract a non-zip file, which prevents you from deleting it. This can happen if the library attempts to open a file that isn’t a valid zip archive, leading to a locked state.

To resolve this issue, follow these steps:

  1. Ensure Proper Disposal: Make sure that the LzipArchive object is properly disposed of after use. You can do this by wrapping it in a using statement, which you already seem to be doing. However, ensure that the Extract method is not causing any exceptions that might prevent disposal.

  2. Check for Exceptions: If an exception is thrown during the extraction process, the file handle may not be released. Log the exception details to understand if this is the case.

  3. Use Try-Catch for Cleanup: In your catch block, ensure that the LzipArchive is disposed of correctly. Additionally, check if the file is still in use before attempting to delete it.

  4. File Access Check: Before attempting to delete the file, check if it is still in use by trying to open it in read mode. If it throws an exception, it means the file is still locked.

Here’s a modified version of your code that includes these suggestions:

try
{
    using (var lzip = new LzipArchive("C:\\demo.eml"))
    {
        lzip.Extract("C:\\tempFolder");
    }
}
catch (Exception ex)
{
    Console.WriteLine($"Error: {ex.Message}");
    Thread.Sleep(3000);
    
    // Check if the file is still in use
    try
    {
        using (File.Open("C:\\demo.eml", FileMode.Open, FileAccess.Read)) { }
    }
    catch
    {
        // File is still in use, handle accordingly
    }
    finally
    {
        // Attempt to delete the file
        try
        {
            File.Delete("C:\\demo.eml");
        }
        catch (IOException ioEx)
        {
            Console.WriteLine($"File could not be deleted: {ioEx.Message}");
        }
    }
}

This code attempts to open the file in read mode to check if it is still in use before trying to delete it. If the file is locked, it will catch the exception and allow you to handle it accordingly.

Please implement these changes and let me know if this resolves your issue or if you have any further questions!

3

No luck
File still cannot be deleted with error “: ‘The process cannot access the file ‘’ because it is being used by another process.’”
is indeed locked by the LzipArchive but with exception occurred, the lzip object is null and i cannot do a force dispose. I think the dispose of file resource should be done inner the LzipArchive.
Thanks,

4

Hello @xieming95at163.com, Could not reproduce the problem, it deletes successfully on my side. I’ve checked the code - it actually releases inner file stream on disposal.

To ensure source file is released by Aspose.ZIP you can pass stream wrapped in using block.

using (FileStream source = File.Open("demo.eml", FileMode.Open))
{                
    using (var archive = new LzipArchive(source))
    {
        archive.Extract("...");
    }
}

BTW, LzipArchive is for lzip/lz archives, not for zip ones.
Can the “demo.eml” be locked with another process?
May be you share the “demo.eml” for us to review?

5

Hello,
Thanks for the help, I try the new way and the file can be disposed correctly with the stream and it works well . So I’m sure that the file is not occupied by other process but the LzipArchive. I think it will be better if your guys could improve the LzipArchive later and make sure that the using state works well even the file is not a zip or it’s corrupted. I’m okay for current workaround.
Thanks again.

6

We confirm the issue with LzipArchive constructor attempting to parse invalid bytes and will fix it in the September version.