Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Fault tolerance: Don't erase captures and edits until we are sure they have been uploaded #266

jamshark70 opened this Issue Aug 9, 2012 · 2 comments


None yet
3 participants

Related issue: #184

That issue is to prevent sync when the network connection is not available. However, this issue is a little broader. The network connection may be available, but transferring captures and edits to the dropbox/Ubuntu one/webdav server may fail for any number of reasons. Currently, MobileOrg sync doesn't care whether it worked or not. It just wipes out the captures, causing data loss for the user.

The best approach I can think of is to add an SHA ID to every captured/edited node (exactly like org-mobile-push does for TODOs and scheduled/deadline items), and transfer this to the sandbox during sync. It would not delete anything at this point. The user should copy new nodes into the desired org file along with the SHA. Then, after the user pushes from Emacs and resyncs on the mobile device, MobileOrg would detect that there is a capture/edit with the same ID and only at that point would it delete the entry. Then there is no chance of data loss -- MobileOrg would not delete anything without confirmation that the data went over to the other side correctly, by getting the same ID back on a subsequent sync.

Short of that, at least be sure that there was no error during transfer.


hdweiss commented Aug 11, 2012

Dataloss is a serious problem. We have already done some work so that mobileorg will become more robust in the future and I will make it my top priority.


hdweiss commented Sep 22, 2012

This is fixed with the dropbox synchronizer.

@matburt can you test if the other synchronizers throw an IOException when they are unable to upload a file?

@matburt matburt was assigned Sep 22, 2012

@matburt matburt added a commit that referenced this issue Dec 4, 2012

@matburt matburt Make sure the Ubuntu Synchronizer emits an IOException if it can't up…
…load a file... this should be the last thing needed to close issue #266

@matburt matburt closed this Dec 4, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment