Here is the most recent log with the new jar in place:status_zip.log (126.0 KB)
Sorry for letting you wait that long, but my witfe prepared a very nice cake…
Wolfgang
lol 
So according to the log it fail while saving the attachment history in the database.
This sounds like a bug but I doubt you really intended to store attachments content in the filesystem but attachment history in the database, did you ? What do you have in xwiki.cfg in the store section ?
It’s really a bit weird what I configured:
# xwiki.store.main.hint=hibernate (intended)
xwiki.store.attachment.hint=file (intented)
# xwiki.store.versioning.hint=file (intented)
xwiki.store.attachment.versioning.hint=hibernate (not intended)
# xwiki.store.recyclebin.hint=file (intened)
xwiki.store.attachment.recyclebin.hint=file (intended)
The reason for this setting come from our system. We build production systems for radio stations which include almost anything from planning of shows, audio editing, large file storage, database and a lot of other tools. In our database we have the metadata for the audio files. For the database the audio is kind of attachment which we definitly do not want to store them within the database just because of the size (it’s all linear audio!). We we talk about history of audio data, then we mean that we want to know whether an audio consists of parts of other audio and that for generations of the audio. But that’s all metadata, so no huge amount of data. That in mind I configured file for all attachment. And in terms of history I obviously made a wrong decision because in terms of xwiki the story is totally different.
Can we change that setiing without confusing anything?
Yes AFAIK in the database the version store also store diff between each version so you do end up with stuff as big as what you have on filesystem at least for the first version of the history and then diffs (and from time to time a new full content is stored to speed up version content resolution).
If it was already like this in 8.4.5 and attachments history was working fine it would be great if you could report a BUG issue on https://jira.xwiki.org/browse/XWIKI.
Now changing this property is not a problem in theory because XWiki support mixed storage. In practice this means that it’s indicated for each attachment where XWiki should store the content and the history so this value is just the default to use for new attachments. But if there is a bug in 9.11.7 with the database attachment history it will still affect old attachment which are not going to be moved to filesystem.