Corrupted Stacks

[Marty Knapp]

Thanks for your input Tom. If I'm not mistaken, isn't that what Dropbox does - saves to a local folder then makes a copy to the cloud? With Richard’s input that Dropbox and similar services are notorious for problems in this regard I can only surmise that it’s the trip over the internet that introduces the opportunity for corruption. But maybe I'm wrong on that.

I was just on the phone with a customer who is periodically (once every 2-3 months) having this issue. He’s on a gigabit network and a 1mb file took about 5 seconds to save before the document closed and the tilde version of the file was deleted. That’s seems pretty slow for that size of file.

Marty


> On Jan 29, 2020, at 9:30 AM, Tom Glod via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> I would change your save routine to save locally first, then copy to
> network location.  That should prevent those kinds of issues.
> 
> On Tue, Jan 28, 2020 at 9:14 PM Richard Gaskin via use-livecode <
> use-livecode at lists.runrev.com> wrote:
> 
>> Marty Knapp wrote:
>> 
>>> I have an app in which users create documents (stacks) that auto-save
>>> when they're closed. I have a a few customers who are getting
>>> corrupted stacks every once in a while. At least in a couple of cases
>>> they are saving to a network server or over an internet connection.
>> ...
>>> Does anyone have any input with my shutdown routine? Ways of making it
>>> more robust?
>> 
>> Save is save.  One command triggers the engine's save routine. Hard to
>> get leaner than that.
>> 
>> As a general rule, I would not advise saving large live documents over a
>> network, or to any folder managed by network sync (Dropbox, iCloud,
>> Nextcloud, etc.).  Tons of warnings from software vendors all over the
>> web about things like that.
>> 
>> Are the users able to recover from the "~" copy?
>> 
>> --
>> Richard Gaskin
>> Fourth World Systems