On February 26, 2018 9:40:58 PM Richard Gaskin via use-livecode <use-livecode@lists.runrev.com> wrote:

There are many ways that imagined scenario might for all I know be
accounted for in the way Dropbox is written.  But there may also be
other scenarios that can produce the same corrupted result that I
haven't thought of.

Just so Marty won't worry too much, Dropbox handles file conflicts:

"If two people change the same file at the same time, Dropbox won't try to merge the changes. Instead, it will save the original file as well as a second version which has the same name but is appended with "conflicted copy," the name of the person or computer responsible, and the date the conflict occurred. By creating a conflicted file, Dropbox ensures that all changes are preserved and nobody will overwrite another person's hard work."

I've seen this happen. It's a pain trying to merge the changes if there are too many but nothing gets lost.

I've seen the occasional corrupted LC stack, most recently just last night, but it was an extreme edge case no one else is likely to encounter and I think I know what happened. The solution was "don't do that."

Jacqueline Landman Gay         |     jac...@hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to