Archiving Errors
Refer to Archiving Stopped if your server has stopped archiving.
Failed To Write
failed to write blob:Expected ZIP64 end of central directory record!)
The error above indicates that an associated archive file is corrupted. If these errors occur persistently, the following are possible causes:
- There is hardware disk corruption/failure.
- A VMWare or virtual storage layer is used that has bugs or problems.
- NFS or SMBFS protocols are used to connect to remote storage. These protocols are not suitable for heavy IO archiving operations. When connecting to remote storage, rather use fibrechannel or iSCSI/ethernet.
- An antivirus product is installed on the same machine as MailArchiva and is interfering with its proper functioning.
- More than one instance of MailArchiva with the same config is running on the same machine. This may happen when customers backup their ROOT folders and place them in the same parent directory location. The only directories that should be present in C:\ProgramData\MailArchiva or /etc/opt/mailarchiva/ are ROOT, core, and logs and Tomcat. Any other directory will cause MailArchiva to create a parallel instance internally.
Point 1 - 4 require an examination of the hardware / OS environment. Provided compaction is disabled in Configuration->Archive, MailArchiva writes to the end of existing archives in append mode. Therefore, with compact disabled, corruption of the archive structure itself should be rare from a software standpoint. In addition to the above points, it is always worthwhile to upgrade MailArchiva to the very latest version. After upgrading, try creating a new volume and closing the existing one.
Repairing a Corrupted Archive File
Examining the debug.log file in Configuration->Logs, a stack trace similar to the below may be revealed:
com.stimulus.archiva.fw: failed to write blob:failed to write blob {filename='D:\Store\049.zz\469\049469be4800b34c7364f7553a1cfab4.nfo'
at com.stimulus.archiva.mu.a(MailArchiva:441) ~[mu.class:na]
at com.stimulus.archiva.mf.a(MailArchiva:183) ~[mf.class:na]
at com.stimulus.archiva.bi.a(MailArchiva:319) [bi.class:na]
at com.stimulus.archiva.bi.a(MailArchiva:231) [bi.class:na]
at com.stimulus.archiva.bi.a(MailArchiva:194) [bi.class:na]
at com.stimulus.archiva.receive.ReceiveService.a(MailArchiva:390) [ReceiveService.class:na]
at com.stimulus.archiva.receive.ReceiveService.a(MailArchiva:515) [ReceiveService.class:na]
at com.stimulus.archiva.kl.a(MailArchiva:131) [kl.class:na]
at com.stimulus.archiva.kn.run(MailArchiva:106) [kn.class:na]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [na:1.7.0_55]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [na:1.7.0_55]
at java.lang.Thread.run(Unknown Source) [na:1.7.0_55]
Caused by: com.stimulus.archiva.fw: failed to write blob {filename='D:\Store\049.zz\469\049469be4800b34c7364f7553a1cfab4.nfo'
at com.stimulus.archiva.mu.b(MailArchiva:1210) ~[mu.class:na]
at com.stimulus.archiva.mu.a(MailArchiva:432) ~[mu.class:na]
... 11 common frames omitted
Caused by: com.stimulus.archiva.fw: Expected 1307 more entries in the central directory!
at com.stimulus.archiva.mw.a(MailArchiva:396) ~[mw.class:na]
at com.stimulus.archiva.mu.b(MailArchiva:1197) ~[mu.class:na]
... 12 common frames omitted
Take note of the stated archive file path in the debug.log file. In this case, D:\Store\049.zz. To fix the corrupted zz file, either replace it from the latest backup or run a Zip repair on the file.
For instance, in Linux, run:
cp 04b.zz 04b.bak
zip -F 04b.bak --out 04b.zz
On Windows, run the Sysinternal Zip Repair Utility (see: http://www.diskinternals.com/download/zip_repair.exe) on the specific file 04b.zz.
Verify the size of the resultant ZZ file to verify whether or not too much data is lost, and whether in fact it would be preferable to restore from backup.
Found this information useful? Visit mailarchiva.com to learn more about MailArchiva.