Affects Version/s: 3.1
Fix Version/s: 4.3-milestone-1
keywords:recycle bin, attachment, file storage system, FS
Documentation in Release Notes:N/A
XWIKI-6951 When using filesystem attachments with attachment versioning disabled, deleted attachments are duplicated on the hard disk. XWIKI-6918 Empty search results of attachments live table while file system storage turned on in multi-wiki mode XWIKI-543 Recycle bin for deleted documents XWIKI-9710 While filesytem is on, attachments are deleted, but folders in storage are not XWIKI-2345 UI for managing the Recycle Bins XWIKI-6071 Add filesystem based attachment recycle bin store. XWIKI-7399 Empty search results of deleted attachments in live table while file system storage turned on XWIKI-7978 File system attachment store recycle bin sometimes fails to list deleted attachments. XWIKI-9567 Cannot restore document translations from recycle bin XWIKI-9421 Attachment version is incremented when a document is restored from recycle bin
Attachment versioning turned off (xwiki.store.attachment.versioning.hint = void)
Storage is set to file system,
Recycle Bin is ON.
To verify attachment versioning is off. The same file attachment several times gives one copy in storage as expected. No problem.
If user deletes an attachment.
Expected behaviour: just to MOVE attachment to recycle bin via file system opertaion. Usually takes milliseconds to complete.
~GLOBAL_DELETED_ATTACHMENT_ID_MAPPINGS.xml appeared in /store folder.
XML inside shows were to find files. Files are on their places as described.
Recycle bin gives terrible surprise: it stores TWO COPIES of deleted file:
first is: <filename>.<extension>
second is: <filename>~v1.1.<extension>
Please note, that attachment VERSIONING is turned OFF.
For big attachments (1GB and more) such a behaviour is a disaster for two reasons:
- unreasonable disk space consumption
- huge delay while user deleting attachment (move+copy)