As the library consumer, i expect, that no (access, timing)-pattern creates an invalid vault structure (TODO: define what this means).
This is not the case under certain conditions. As an example:
If a shortened file is simultaneously deleted and moved, there is a short timing window, where at the destination already files were created, but the actual content file is deleted. The move fails with an exception, but the residual files are not cleaned up.
Specifically, if the moving thread is put on hold before line 600, another thread can delete the content file (because in openCryptoFiles the mapping for the old path exists). Line 600 will fail, but the filesystem nodes created in the line before are not deleted.
https://github.com/cryptomator/cryptofs/blob/b3755f354e4d57d47ab655cf43e8d83c41685c25/src/main/java/org/cryptomator/cryptofs/CryptoFileSystemImpl.java#L590-L606
Another example is deleting a file, to which a new file channel is opened with the CREATE flag. TODO: elaborate once #170 is fixed.
As the library consumer, i expect, that no (access, timing)-pattern creates an invalid vault structure (TODO: define what this means).
This is not the case under certain conditions. As an example: If a shortened file is simultaneously deleted and moved, there is a short timing window, where at the destination already files were created, but the actual content file is deleted. The move fails with an exception, but the residual files are not cleaned up. Specifically, if the moving thread is put on hold before line 600, another thread can delete the content file (because in openCryptoFiles the mapping for the old path exists). Line 600 will fail, but the filesystem nodes created in the line before are not deleted. https://github.com/cryptomator/cryptofs/blob/b3755f354e4d57d47ab655cf43e8d83c41685c25/src/main/java/org/cryptomator/cryptofs/CryptoFileSystemImpl.java#L590-L606
Another example is deleting a file, to which a new file channel is opened with the CREATE flag. TODO: elaborate once #170 is fixed.