Details
-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
17.10.7
-
None
-
Unknown
-
Description
When using the Hibernate (database) attachment versioning store, uploading an attachment for the first time creates version 1.1 but does NOT seed the JRCS archive. When the same attachment is re-uploaded (creating version 1.2), the archive is loaded empty, the version is incremented to 1.2, and a fresh JRCS Archive is created seeded only at 1.2 — making version 1.1 unrecoverable. All subsequent updates (1.2 → 1.3, etc.) work correctly.
Steps to reproduce:
- Configure xwiki.cfg with xwiki.store.attachment.hint=hibernate and xwiki.store.attachment.versioning.hint=hibernate
- Upload any attachment (e.g. test.txt) to a page — it appears as version 1.1
- Upload the same filename again with different content — version 1.2 is created
- View the attachment revision history — only version 1.2 is listed; version 1.1 is gone
Expected: Both 1.1 and 1.2 appear in the history.
Actual: Only 1.2 appears; 1.1 is silently lost.
Root cause: HibernateAttachmentVersioningStore.saveArchive() does not seed an empty archive before persisting it, unlike AttachmentArchiveSaveRunnable (filesystem store) which explicitly calls archive.addCurrentAttachment(context) when archive.getVersions().length == 0.
Fix: In saveArchive(), check archive.getRCSArchive() == null && archive.getAttachment() != null and call archive.addCurrentAttachment(context) before the DB write.
Affects: All XWiki versions using the Hibernate attachment store (confirmed on 15.10.x, 16.10.x, 17.10.x).
Forum report: https://forum.xwiki.org/t/attachments-v1-1-are-lost-when-being-updated/18417