Quit Command corrupts standalone (stack called by standalone splash)
J. Landman Gay
jacque at hyperactivesw.com
Tue Feb 27 02:37:51 EST 2018
On February 26, 2018 9:40:58 PM Richard Gaskin via use-livecode
<use-livecode at 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 | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
More information about the use-livecode
mailing list