replicator.org ... continuous garbage collection

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:

Beyond bug fixes, we are working at some minor enhancements. One of them is Recycle Bin support.

Beginning with build 1852, files that are deleted in the synchronization process may be moved to the Recycle Bin:

For new linked folders, this option is enabled by default. For existing ones, it is disabled.

And for us, the next step is to release the closed beta. Follow us on Twitter or Facebook to help us improving SharedSafe.

We are starting to use our new file system tester, and immediately found and fixed two important bugs:

• When too many changes happen in a file system tree, the synchronization stopped:
  This was a subtle problem in handling a buffer overflow in the FileSystemWatcher. Now, when too many changes are happening, the internal file system tree is flushed and rescanned for the next synchronization. Not the best solution, but a safe one. An alternative would be to run a high-priority thread that retrieves all the changes in time. But even then, it can not be guaranteed that this error won’t happen anymore. So I think it is better to handle it anyways.
• Files could not be write-accessed or deleted while they were transferred:
  I knew of this problem, but never observed it in one of the test cases, but our new file system tester catched this one easily. From now on, files are uploaded in “stealth” mode.

Finally, we are moved the code base into private beta. We changed the license to a new one we got from our lawyer and fixed some serious security problems:

Though I made a two week detour to create a small Silverlight based graph editor, SharedSafe is progressing well and we are finally glad to announce another alpha release. Yes, I know, we planned get into the beta phase weeks ago, but because the Website is not ready yet, it may take another two weeks until we start the private beta. I am sorry for that, but we want to base everything on solid ground.

So what is new?

Some time ago we decided to change the terminology to reflect in a more logical sense what it means to connect local Folders with remote IMAP Folders. We changed the following:

• A Store is now a Safe
• A local folder, that is synchronized with a Safe, is now a Linked Folder
• An exported Safe (a file suffixed with “.sharedsafe”) is now called a SafeKey, and the file extension is also “.safekey”.
  So if you have exported safes lying around, just rename them from *.sharedsafe to *.safekey.

Based on the new terminology, we implemented a new set of Explorer context menus:

Create Safe and link to Folder will present you with options to create a new Safe and immediately links the Safe to the selected folder. If the folder already contains files, they will be uploaded immediately.