Quit Command corrupts standalone (stack called by standalone splash)

[J. Landman Gay]

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