We’ve integrated file hashes in the Safe file system.
Right now, this impacts the feature set only marginally, but over the next few weeks and before the public beta, we will use hashes to implement some new features in the synchronization engine.
The changes in the build 1911:
-
We fixed a bug in the manual synchronization where the Recycle Bin option was enabled but not actually used.
-
Read errors are now handled much more generously in the synchronization. For example, large files that are deleted while uploaded should not cause any errors.
-
Unlinking and relinking a Folder to a Safe does not cause the contained files to be marked as conflicts anymore. This works only for files that have been uploaded beginning with build 1911. Older files will be marked, because there is no hash information available.
Based on the file hashes, a number of new features are now in preparation:
-
File Renames / Moves
By using hashes, SharedSafe will reuse the blocks that were uploaded to the Safe, so that a file rename will result in a minimal upload. We need to use hashes, because by design, and very intentionally, our Safe file system has no concept of a “Rename” primitive. Implementing Renames is on top of our list.
-
File Copies
We are not yet sure if we want to support this, but it may save a lot of storage space. The problem here is that we can not detect – without actually comparing the hashes of file with all the others – if the content of two files is the same. To avoid hash collisions, we would like to keep the comparisons restricted to the hashed blocks of one file only.
-
Interrupted Uploads
When uploads get interrupted, SharedSafe just retries from the beginning. Obviously, this is not an option for larger files or unstable Internet connections.
-
Partial file Changes
This is a feature that is required for very large files. For example TrueCrypt images or database files that need to be synchronized with a minimal upload.
-
Verify Hashes on File Creation
Because of the compression, encryption, signing and encoding of one IMAP mail, SharedSafe should already spot any data corruption (for example in case of a flipping bit, or an implementation error). In addition, comparing the hashes while or after writing the blocks to the file system could really prove the consistency of a file synchronization from end to end.
But because we got a lot of great feedback in response to our closed beta release (thank you all!), we decided to move our focus away from hashes for the next iteration. Here are the upcoming changes for the next version:
Fix Bugs
There are some problems reported with spooky recreation of files. Right now we have no idea why this happens, or if it is already fixed. Please stay with us and report these problems if they happen again.
Dynamic IMAP Polling
We poll the IMAP server every 30 seconds for changes. This is a lot more often than most IMAP mail clients. For the next update we will increase it to 60 seconds in case of idle periods, but reduce it to 30 seconds for a number of minutes after a change has been detected in the Safe.
Memory Optimization
We just did not care about memory yet, but a lot of the buffers SharedSafe is using can be easily recycled. We hope to reduce the peak memory consumption considerably.
Task Dialogs
Dialogs may show new input controls dependent on previous user input. Right now, this leads to unwanted and unexpected scrolling and often requires the user to move the scrollbar. We need to find a way to improve the experience here.
Again, I’d like to thank all our beta testers! You already had a huge impact on the product!
The motivation to get SharedSafe out of the door just peaked this week, and we would like you to continue sending us your first impressions, ideas and bug reports.
And now, get the new version :)