Problem BlobWriteMode.CREATE_NEW is meant to fail with BlobAlreadyExistsException when the target blob already exists. When the filesystem blob store moves a blob (moveBlob) with CREATE_NEW, it calls Files.move(source, target) without options. On Unix, the JDK checks that the target doesn't exist and then calls rename(2), which silently replaces an existing target. Between the check and the rename, another writer can create the target: both moves then succeed and the last one wins, instead of the second one failing. The code comment next to the call describes the operation as atomic. Copies and writes are not affected: Files.copy and the output stream of a filesystem blob open the target with CREATE_NEW (O_EXCL), which is atomic. In XWiki, attachment content is saved by moving a temporary blob to its final path with the default CREATE_NEW mode, so concurrent saves of the same attachment that are not serialized elsewhere can overwrite each other without an error. Found by reading the code during the review of XCOMMONS-3823; not reproduced with a test. Possible fixes
- Move with a hard link: Files.createLink(target, source) fails atomically with FileAlreadyExistsException when the target exists (link(2) returns EEXIST); then delete the source. On file systems without hard links, copy with CREATE_NEW and delete the source.
- Or keep the current behaviour and rely on the documentation of CREATE_NEW, which XCOMMONS-3823 changes to say that the check and the write are not guaranteed to be atomic.
|
