Closed infeo closed 9 months ago
The recent updates to the Cryptomator project focus on enhancing data integrity, synchronization, and file timestamp accuracy during file operations. A significant change is the adjustment in handling file channel closures, shifting from CleartextFileChannel
to a broader FileChannel
interface. The modifications also include better synchronization mechanisms through the introduction of a PriorityMutex
and adjustments in channel management logic to maintain consistency and correctness, particularly in the context of last modified timestamps.
Files | Change Summary |
---|---|
.../ch/ChannelCloseListener.java .../fh/OpenCryptoFileTest.java |
Updated parameter type in closed method; Adjusted test for new parameter type. |
.../ch/CleartextFileChannel.java |
Added annotations for testing; Enhanced channel closing logic; Added comments. |
.../fh/ChunkIO.java .../fh/PriorityMutex.java |
Introduced PriorityMutex for better synchronization; Refactored for simplicity and thread safety. |
.../fh/OpenCryptoFile.java |
Shifted from ConcurrentHashMap to AtomicInteger for open channel tracking; Updated channel management logic. |
.../ch/CleartextFileChannelTest.java |
Enhancements in testing, including handling IOException scenarios and refining method calls. |
Objective | Addressed | Explanation |
---|---|---|
Address the issue where closing the cleartext file channel might change the lastModified timestamp due to the order of operations. (#205) | ✅ | |
Ensure that the lastModified timestamp correction is not nullified by unwritten changes in the channel. (#205) | ✅ | |
Implement explicit flushing of the ciphertext channel before setting the last modified time to prevent unintended changes. (#205) | ✅ | |
Review the flush() method in CleartextFileChannel to consider all necessary write operations, not just for the chunk cache. (#205) |
✅ | |
Evaluate the necessity of explicitly flushing the ciphertext channel to maintain data integrity and timestamp accuracy. (#205) | ✅ |
In the realm of encrypted files, Where data securely smiles, A rabbit hopped through code and style, Ensuring timestamps reconcile. 🐇💾
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
I'll open a new PR with fewer changes.
Fixes #205.
Unfortunately, the changes became bigger than anticipated. Reason is, that due to our ..."spaghetti" architecture, with the minimal fix could not exclude the possibility that the lastModified timestamp is not overwritten. The chunkCache uses an arbitrary ciphertext filechannel to write to a file via the
ChunkIO
class. It was theoretically possible to first get a writable channel but deregister this channel in a different thread. With my implementation one can either deregister channels to the same file or write into such channels, but cannot do both. Deregistering is prioritized to timely finish close actions.With this PR we have now the guarantee, that between a ciphertext channels
force(...)
andclose()
method, no other thread can write to it, hence persisting the lastModified timestamp can only fail on the storage side. Additionally, i moved all IO-related things during close to theCleartextFileChannel
(some were lingering around inOpenCryptoFile
) and improved the unit tests.Summary by CodeRabbit
IOExceptions
.