Archived Forum Post

Index of archived forum posts

Question:

WriteZipAndClose error in multithreaded environment

Dec 01 '14 at 12:16

Hi I am having an intermittent errors in multithreaded environment when CkZip's method WriteZipAndClose is called. I am using java library wrapper. Each thread is responsible for compression of individual file. All files ( original and compressed) have unique name and stored in a single directory. The problem appears to take place in case of concurrent requests due to the fact that temporary file, created during a call to WriteZipAndClose() is stored in the same directory ( by default) and does not have unique name. Please find below text, returned by lastErrorText(). For example, in below log the name of the tmp file is ckz_PYWW.tmp, instead of convention based on the source or target file name, which is unique. Is my observation accurate? Is it possible that such name collision take place due to several hundred concurrent requests? I cannot seam find a way in the object model to control the name of the tmp file. Is this correct? I was able to work-around this by creating a temporary directory with unique name for each file being compressed and setting location of the temporary file to this location, using CkZip's setter put_TempDir(). Is there a better way? I acknowledge that I am not using the latest version of chilkat library (9.2.0). However browsing through release notes I could not find anything, related to this in most recent releases.

Thanks, Igor

ChilkatLog:
  WriteZipAndClose:
    DllDate: Aug  3 2011
    UnlockPrefix: GENNADZIP
    Username: SERVER:test
    Architecture: Little Endian; 64-bit
    Language: Windows Java
    Using temp directory where target Zip is located.
    tempFile: \\host\mstrroot\FileExportRepository\Work\FileExportsDelivery\Reports\99FD76B5455222636E78C388DDA5A9EF\ckz_PYWW.tmp
    Encryption: 4
    PasswordProtected: 0
    CentralDirOffset: 11613
    NumCentralDirRecords: 1
    EndOfDirectoryOffset: 11722
    closeHandle:
      windowsHandle: 8568
    zipFilename: \\host\mstrroot\FileExportRepository\Work\FileExportsDelivery\Reports\99FD76B5455222636E78C388DDA5A9EF\4907-Summary.zip_848_200019936_.processing2014-10-15 15.22.22.118.zip.compressed
    MoveTempToDestZip1:
      WindowsError: The process cannot access the file because it is being used by another process.
      WindowsErrorCode: 0x20
    MoveTempToDestZip2:
      WindowsError: The system cannot find the file specified.
      WindowsErrorCode: 0x2
    TempFileCleanup:
      WindowsError: The system cannot find the file specified.
      failedToDeleteFilepath: \\host\mstrroot\FileExportRepository\Work\FileExportsDelivery\Reports\99FD76B5455222636E78C388DDA5A9EF\ckz_PYWW.tmp
    currentWorkingDirectory: C:\Windows\system32
    from_filename: \\host\mstrroot\FileExportRepository\Work\FileExportsDelivery\Reports\99FD76B5455222636E78C388DDA5A9EF\ckz_PYWW.tmp
    to_filename: \\host\mstrroot\FileExportRepository\Work\FileExportsDelivery\Reports\99FD76B5455222636E78C388DDA5A9EF\4907-Summary.zip_848_200019936_.processing2014-10-15 15.22.22.118.zip.compressed
    Failed to move Zip file
    Failed.

Answer

I believe the issue with temporary files created, using potentially duplicate names is resolved in the latest version. I have used small utility that utilizes CLR's FileSystemWatcher to monitor locations where tmp files can be potentially created (i.e. current working dir, location, specified by put_TempDir). Unlike in 9.2.0 tmp files are no longer created if I use the 9.5.0.