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@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@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." _______________________________________________ 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