Re: Corrupted Stacks
I use Chronosync. You can schedule them or run them manually. One way or two way syncs. Control over things I never even knew existed. Lifetime license. Bob S > On Jan 29, 2020, at 15:26 , Matthias Rebbe via use-livecode > wrote: > > Which one are you using? > > - > Matthias Rebbe > Life Is Too Short For Boring Code > >> Am 29.01.2020 um 23:50 schrieb Bob Sneidar via use-livecode >> : >> >> I have a sync program sync my projects folder to my iCloud drive. >> >> Bob S ___ 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
Re: Corrupted Stacks
Which one are you using? - Matthias Rebbe Life Is Too Short For Boring Code > Am 29.01.2020 um 23:50 schrieb Bob Sneidar via use-livecode > : > > I have a sync program sync my projects folder to my iCloud drive. > > Bob S > > >> On Jan 29, 2020, at 14:30 , Matthias Rebbe via use-livecode >> wrote: >> >> Matthias Rebbe >> Life Is Too Short For Boring Code >> >>> Am 29.01.2020 um 22:00 schrieb Marty Knapp via use-livecode >>> : >>> >>> 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? > > ___ > 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 ___ 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
Re: Corrupted Stacks
I have a sync program sync my projects folder to my iCloud drive. Bob S > On Jan 29, 2020, at 14:30 , Matthias Rebbe via use-livecode > wrote: > > Matthias Rebbe > Life Is Too Short For Boring Code > >> Am 29.01.2020 um 22:00 schrieb Marty Knapp via use-livecode >> : >> >> 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? ___ 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
Re: Corrupted Stacks
- Matthias Rebbe Life Is Too Short For Boring Code > Am 29.01.2020 um 22:00 schrieb Marty Knapp via use-livecode > : > > 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 https://devblogs.microsoft.com/scripting/how-can-i-determine-which-drives-are-mapped-to-network-shares/ 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@192.169.9.100/Syn%206%20TB on /Volumes/Syn 6 TB (afpfs, nodev, nosuid, mounted by matthias) The network drive is the one with the 2 leading / Matthias > > Marty > >> On Jan 29, 2020, at 11:48 AM, Matthias Rebbe via use-livecode >> 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 >>> : >>> >>> 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 >>>> 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@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ 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
Re: Corrupted Stacks
Marty Knapp wrote: > 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. Hard to say what these cloud sync services may find problematic. Most of issues I've read about are with paging formats like SQLite, e.g.: https://stackoverflow.com/questions/7003336/how-enable-icloud-support-for-sqlite Since LC writes in one clean step I'm surprised it would have an issue, but while looking into this recently I stumbled across a lot of people who are having issues with Excel files corrupting in sync services. IIRC Dropbox uses - or at least once used - WebDAV, and Nextcloud and others still do. This makes the sync issue more vexing because WebDAV does whole-file transfers, as opposed to patching. So unfortunately I have little I can confidently convey on this, beyond having seen a lot of vendors using SQLite and other paging formats recommend not working directly in synced folder. > 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. The time between the engine's deletion of the "~" file and it's *apparent* deletion in a file manager may be quite different, as many file managers don't immediately re-render file listings in the UI, deferring it until a few ms after idle (or in the case of Windows, I've seen GUI file listing updates take a few seconds). This time may also be affected by the polling rate of any cloud sync service used with the folder. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.com ___ 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
Re: Corrupted Stacks
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 (iCloud, etc). I wonder, is there a reliable way to ascertain if the file is on a server? Marty > On Jan 29, 2020, at 11:48 AM, Matthias Rebbe via use-livecode > 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 >> : >> >> 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 >>> 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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Corrupted Stacks
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 > 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@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 ___ 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
Re: Corrupted Stacks
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 > : > > 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 >> 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@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ 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
Re: Corrupted Stacks
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 > 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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Corrupted Stacks
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@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 > > > > ___ > 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 > -- Tom Glod Founder & Developer MakeShyft R.D.A (www.makeshyft.com) Mobile:647.562.9411 ___ 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
Re: Corrupted Stacks
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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Corrupted Stacks
I'm wondering if save stack returns anything in the result so you can check for success? Bob S > On Jan 28, 2020, at 14:19 , Marty Knapp via use-livecode > 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. In some cases it seems to > occur when they quit with a stack open. I've attempted to script around this > by checking for the tilde version of the file and if it exists to pause > quitting. > > I would say the stack size varies between 1 to 5 mb in size. App build with > LC 9.5.1 and a mix of Mac and Windows standalones. > > Does anyone have any input with my shutdown routine? Ways of making it more > robust? ___ 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
Corrupted Stacks
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. In some cases it seems to occur when they quit with a stack open. I've attempted to script around this by checking for the tilde version of the file and if it exists to pause quitting. I would say the stack size varies between 1 to 5 mb in size. App build with LC 9.5.1 and a mix of Mac and Windows standalones. Does anyone have any input with my shutdown routine? Ways of making it more robust? Local sMyTildeFilename on shutDownRequest Global gOpenDocument,gLastDocumentOpen --gOpenDocument contains the name of a currently open stack (if any) --gLastDocumentOpen contains the fileName of the last open stack --in case it was closed before quitting if gOpenDocument is among the lines of the openStacks then put the fileName of stack gOpenDocument & "~" into sMyTildeFilename save stack gOpenDocument close stack gOpenDocument else put gLastDocumentOpen & "~" into sMyTildeFilename --Don't allow quit until the temp file is deleted: if there is a file sMyTildeFilename then send quit to me in 1 second else pass shutDownRequest --Lets it quit end shutDownRequest Marty ___ 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
