I am an end user who runs a software which usess TrueZIP. Whenever the software tried to insert an element into a ZIP file, the application log filled with:
2012-12-06 18:12:59,241 WARN [SchedulerWorker-ZipArchiver-11,] (ZipArchiverService) - Could not archive /xxxxxx/YYYYYYYYYYYYY/zzzz/bbb/sssssssss/optlink/files/2012/12/06/18/47f2dab5-0f67-4382-9
71b-0f961f2a6dce inside archive /xxxxxx/YYYYYYYYYYYYY/zzzz/bbb/sssssssss/optlink/files/archive/2012/12/06/5959b628-1bed-4620-a6f1-954560b9df72.zip, source file exists, archive exists
The outcome of the operation was a 22 Byte empty ZIP file (so the minimum size of a ZIP). However, sometimes the operation succeeded after I removed all the orphan ZIP files from previous operations. In a shell, the successfully filled ZIP would then appear as an directory in Suse SLES 11. Weird enough.
I tried almost everything to find the cause since many other machines running the same software would not show this issue. I reproduced the issue at least with
- Apache Tomcat 7.0.22 and 7.0.32
- Oracle Java 1.6.0_35 and openJDK 1.6.0_24
- ext3 and ext4 file systems
I changed various other minor system parameters like file and folder ownership, umask, etc. without solving the issue.
I finally found that I initially installed the software into a folder which I used a symbolic link in "/" for to shorten the path. So all configuration options would use my symbolic link name instead of the full path name. So I configured the actual path and the issue was gone. Hooray!
As a test, I inserted a symbolic link into my configuration randomly. Instead of using "/path/opt/files" I created a symbolic link "/path/optlink/files", where optlink is a symbolic link to opt in the very same folder (and filesystem, of course. The issue reappeared.
At least in the environment described above, symbolic links seem to break one or more methods of TrueZIP.