Question:
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.
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.