[Windows Mobile Apps and Games] elecconnec:
Just in case DK is still around, or to potential purchasers of the app, I'll make a few comments. Overall it's a good app, and certainly worth $2, but unfortunately there seems to be a few major flaws in the DroppedBoxx sync logic.

Based on my testing and observations, DroppedBoxxed bases sync simply on date/time of last sync. The logic goes something like this:

1) If the version of the file on the device is newer than the last time of sync and newer than the version in the cloud, (or the cloud doesn’t have that file) upload it.

2) If the version of file in the cloud is newer than the one on the device, download it.

So far so good. Here’s the problematic logic:

3) If the cloud has a file older than the last sync and that file doesn’t exist on the device, assume the file has been deleted from the device and delete it from the cloud.

4) If the file on the device is older than the last sync and doesn’t exist in the cloud, delete it from the device, assuming it has been deleted from the cloud.

Those seem like reasonable assumptions, but they can get you in trouble. If, for example, you _move_ a file from one Dropbox folder into another using the web interface, that file may well be older than the last sync date and gets deleted on the next sync, since it fails Logic test #3. Or, if you copy files from your PC to the device’s SD card using a card reader, those files will have the PC’s file date, which again might be older than last sync, and get deleted by DroppedBoxx at next sync by logic #4.

Also, files moved from one folder on the device to another synced folder using the device’s File Manager also get deleted if the file date is older than last sync by logic #4. For example, I sync my \My Documents folder and my \Storage Card\My Docs folder with DroppedBoxx. If I move a file from main memory to Storage to clear up room in main memory, it gets deleted next sync, because the original is gone, which then deletes _it_ from the cloud, and the moved file is now older than last sync, and doesn’t exist in the cloud _at that folder_, so DroppedBoxx deletes it from the device and doesn’t sync it to the Cloud folder. The only way to prevent this is to open it after moving it and make some small edit (add a space, whatever) to reset the file date before the next sync.

Understand I’m not writing this to crap all over DroppedBoxx. It’s a good app and a great value for the money, and I use it to backup my WinMo devices as well as keep them in sync with each other. I’m only pointing out that true file sync is a delicate and difficult procedure, and DroppedBoxx uses a very simplistic approach that makes some dangerous assumptions for expediency.

A “permanent” solution would require DroppedBoxx to keep some kind of log file of all files synced with times and dates of last sync and/or deletion on the device and use that to determine whether to sync or delete, like Activesync/WMDC does and Live Mesh for Windows Mobile did. Any file not in the log file would be presumed “new” regardless of the actual file date and sync. This would prevent all of the accidental deletions. Keeping a log would also prevent the needless “ghost” resyncing of already synced files. (For example, DroppedBoxx uploads a new file created on the device at 8:00AM to the cloud at your next sync, say at 10AM. Now the file in the cloud is “newer” than the one on the device, since it has the 10AM current date/time. At the next sync, the “10AM” file is downloaded to the device replacing the 8AM version, even though they are identical, because the cloud copy is two hours “newer.”) This consumes a lot of unnecessary data, particularly for larger files like photos. If the device had a log file that “told” DroppedBox “photo007.jpg last sync 10:00AM” DroppedBoxx would compare that sync time to the date of the cloud version and realize the file is in sync. More importantly, if a file on the device with an old file date (like a file you transferred from your PC) hadn’t synced yet, it would NOT have a log entry, and therefore would be synced, rather than deleted. (If a previously synced file was deleted from the DropBox cloud, DroppedBoxx would notice that file had a log entry, and therefore delete it and the log entry, since it was a file previously synced.)

This would require a major rewrite and is probably beyond what we can expect from the developer of a $2 app!

I’d like to suggest a few much simpler fixes that would take comparitively little effort : any file deleted from the device by DroppedBoxx should get a “Delete File So-and-so?” Yes/No/Yes-to-All/No-to-All dialog box. Any file _not_ deleted would then get the file date _changed to the current sync time_ to prevent deletion next sync. This would require no change to the sync logic, just the kludgey insertion of the dialog box at any point in the code where a file would be deleted from the device, and a forced file date/time change to futureproof it in subsequent syncs.

The second idea would require less user interaction at sync, but be more work for the developer: create a DroppedBoxx Trash Bin on the device. All deleted files would be moved to it for user review later. Files “restored” from the bin would be reset to the _restored time/date_ to ensure syncing without deletion at next sync.

As an alternative to idea #2, I offer #3: instead of a trash bin, _upload_ any file on the device about to be deleted by the app that doesn't exist in the cloud to DropBox and immediately delete it up there. That way, it could at least be recovered using DropBox’s existing restore feature using the web interface, and should download and be restored at next sync.

The existing logic just has too many situations where a file can be deleted from the device BEFORE ever being uploaded to Dropbox, preventing any type of recovery, which makes DroppedBoxx far too dangerous to sync important files. Any of my suggestions would mitigate that, so users, with a little effort, could recover any files unintentionally deleted by the simple sync logic.

Again, thanks to DK for a good program. As is, it provides a decent method of backup/sync if one is careful to “outwit” the flaws in the sync logic. With some slight changes and a clear explanation to users of why files might “mysteriously” disappear, it could be a much better program with minimal effort on the developer’s part.