Corrupted Stacks

matthias_livecode_150811 at matthias_livecode_150811 at
Wed Jan 29 17:30:31 EST 2020

Matthias Rebbe
Life Is Too Short For Boring Code

> Am 29.01.2020 um 22:00 schrieb Marty Knapp via use-livecode <use-livecode at>:
> That’s an interesting approach Matthias. Most of my customers save locally to their Documents folder. It’s just a few people using filer servers or Dropbox
I´d never problems with Dropbox. I am saving all of my projects to my Dropbox account. I´ve never ran into any problem with saving the main stacks or any substacks.

While you are mentioning iCloud. I´ve noticed that i have problems building and saving a standalone in the Desktop or Documents folder since i´ve  setup iCloud drive to synchronize my Desktop and Documents folder. Sometimes it works and sometime the standalone is not creaed successfully. So maybe iCould Drive is working other than Dropbox. Since i save the standalones to a local volume i did not run into that problem anymore.

> (iCloud, etc). I wonder, is there a reliable way to ascertain if the file is on a server?

To find out if a Windows drive is mapped to network share  you could see here

On Mac OS you could use mount in Terminal. This command without any parameter lists you all mounted drives. The following is the result of mount on my Mac
mattes:~ matthias$ mount
/dev/disk3s1 on / (apfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk3s4 on /private/var/vm (apfs, local, noexec, journaled, noatime, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
/dev/disk1s1 on /Volumes/CCC Backup iMac (hfs, local, nodev, nosuid, journaled, noowners)
//matthias at on /Volumes/Syn 6 TB (afpfs, nodev, nosuid, mounted by matthias)

The network drive is the one with the 2 leading /

> Marty
>> On Jan 29, 2020, at 11:48 AM, Matthias Rebbe via use-livecode <use-livecode at> wrote:
>> Hi,
>> i´ve ran into a similar situation a few months ago. This is what i´ve done.
>> I´ve saved the stack to the local temp folder and then used the revcopyfile command to copy it to the network drive.
>> When opening the app and that stack i used revcopyfile to copy the stack from the network drive to the local temp folder and opened that copy of the stack.
>> So always the stack in to the local temp folder is used, but a copy is made to the network drive everytime i save the stack.
>> This takes some time, but it´s acceptable and it works pretty well.
>> -
>> Matthias Rebbe
>> Life Is Too Short For Boring Code
>>> Am 29.01.2020 um 19:08 schrieb Marty Knapp via use-livecode <use-livecode at>:
>>> Thanks Richard. What would be considered a large file? In my case I would guess the average file is around 1mb though in some cases it could be up to 5mb.
>>> In some cases the user has been able to recover from  the “~” file but not always. But it’s disconcerting to them that they never know when it might happen again. And it’s amazing how many people don’t have a backup plan in place.
>>> Marty
>>>> On Jan 28, 2020, at 6:12 PM, Richard Gaskin via use-livecode <use-livecode at> 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
> _______________________________________________
> use-livecode mailing list
> use-livecode at
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:

More information about the use-livecode mailing list