At the beginning it is ensured that the file is really modified (dirty) and after successful upload this attribute is set to false (L50).
Since the Uploader and the FileFactory are operating on the same files, it can happen that during the upload another thread writes to the file. If the write operation is finished before the upload and the modifed file location was read before its change, the dirty flag of the file is set to false due to finished upload, even thou it has some changes and should be set to true.
Suggested Solution
If an upload is scheduled, a copy of the file is made which only the uploader reads and afterwards deletes. With this approach the file cache and the upload task are seperated and do not need to worry about conflicts. On the downside this doubles the needed cache size. Also it needs to be considered if during the copy process for the upload task the file should be set to read-only.
Alternative Considered
The upload task keeps the original file and the cache works on a (initially empty) copy: This would require less copy operations/saves time, but increases complexity because a new layer needs to be introduced which delegates the filesystem calls to the correct temporary file.
Always keep two copies of a file: A consequence of this approach would be the doubled cache size, which seems not a good idea for big files.
Description
If the last handle to a modified file is closed, the file is scheduled to be uploaded to cloud storage provider. The actual upload is performed by
OpenFileUploader::scheduleUpload(): https://github.com/cryptomator/fuse-cloud-access-adapter/blob/b206f066c7558bde7d29b1ac0d3df51eb8baad7e/src/main/java/org/cryptomator/fusecloudaccess/OpenFileUploader.java#L42-L60At the beginning it is ensured that the file is really modified (dirty) and after successful upload this attribute is set to false (L50).
Since the Uploader and the FileFactory are operating on the same files, it can happen that during the upload another thread writes to the file. If the write operation is finished before the upload and the modifed file location was read before its change, the dirty flag of the file is set to
falsedue to finished upload, even thou it has some changes and should be set totrue.Suggested Solution
If an upload is scheduled, a copy of the file is made which only the uploader reads and afterwards deletes. With this approach the file cache and the upload task are seperated and do not need to worry about conflicts. On the downside this doubles the needed cache size. Also it needs to be considered if during the copy process for the upload task the file should be set to read-only.
Alternative Considered
The upload task keeps the original file and the cache works on a (initially empty) copy: This would require less copy operations/saves time, but increases complexity because a new layer needs to be introduced which delegates the filesystem calls to the correct temporary file.
Always keep two copies of a file: A consequence of this approach would be the doubled cache size, which seems not a good idea for big files.