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:
https://www.dropbox.com/help/syncing-uploads/conflicted-copy
"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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
