Autosaving stacks corrupted on network drives

Mike Kerner MikeKerner at roadrunner.com
Tue Oct 24 19:01:49 EDT 2017


Yes, this especially happens with simultaneous sync tools such as google
drive (now backup and sync), microsoft ,oneDrive box, and dropbox.  There
are a variety of things that play into this annoying behavior, but the most
common one is timing and latency/connectivity.  It really gets to be bad if
you  quit/save from one machine, and then fire it up from another before
the sync/save is complete.

Possible solutions:
1) Do what LibreOffice does.  Create an invisible semaphore file that the
stack checks for on open.  If it exists, the open is rejected and the stack
immediately closes.  This will keep secondary and simultaneous users from
getting their grubby paws into the stack before the save/sync is complete.
As part of this solution, I would suggest any quit/closeStack event has a
built in delay to confirm that the sync/save has completed before removing
the semaphore.  This is still tricky as you are at the mercy of the
sync/save tool, however, if you're clever, you can use the service's api to
check, separately, if the sync/save is complete before you let LC finish
closing down.
2) Split the data out into a separate data file or better into a database
(because most databases use transactions, with greatly minimizes the
probability of corruption).

On Tue, Oct 24, 2017 at 3:55 PM, tbodine via use-livecode <
use-livecode at lists.runrev.com> wrote:

> Hi all.
>
> Looking for your insights on an issue. Here's the scenario..
>
> I have a standalone Win/Mac app that autosaves user data to a stack file as
> the user moves from card to card. Typically, files reach sizes of 100-200k.
> Normally, this works great. But a couple of times a year, some user will
> manage to get corrupted data causing his stack files to be unusable.
>
> I've opened some of these corrupt stack files in a text editor and found
> the
> data loss shows the Save operation was interrupted. There's no garble. Just
> an abrupt end to the data and the file.
>
> I've found a common link in these cases -- either the app is on a network
> drive or the stack file is on a network drive.
>
> My theory is that network save operations are slower than saving on a local
> drive, and somehow this contributes to the data loss. But how?
>
> All theories (except conspiracy) are welcome!
>
> Thanks,
> Tom B.
>
>
>
>
>
>
> --
> Sent from: http://runtime-revolution.278305.n4.nabble.com/Revolution-
> User-f278306.html
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."



More information about the use-livecode mailing list