Okay I think I see what is going on here. A Livecode stack, though it appears to be open in the IDE, is NOT open from the OS point of view. To test this, create a new livecode stack, save it, then attempt to delete it in the OS while it's still open in the IDE. If my theory is correct, you should have no problem doing so.
I did this and sure enough, I was able to put the file in the trash, AND THEN EMPTY IT! But when I saved again in the IDE, it recreated the file. Bob S > On Oct 25, 2017, at 09:26 , Mike Kerner via use-livecode > <use-livecode@lists.runrev.com> wrote: > > Now if what you're suggesting is that the server OS should manage the > access process so that you cannot have two simultaneous accesses, I would > agree, but my experience has been that it doesn't always work that way. > > On Wed, Oct 25, 2017 at 12:19 PM, Mike Kerner <mikeker...@roadrunner.com> > wrote: > >> I'm saying that it is possible to access the same file from the same share >> from multiple machines and leave the file in an indeterminate or corrupted >> state, afterwards, especially if both machines accessing the share are >> trying to save changes to said file. The purpose of the semaphore would be >> to stop the simultaneous access of the file from multiple machines. >> >> >> On Wed, Oct 25, 2017 at 11:54 AM, Bob Sneidar via use-livecode < >> use-livecode@lists.runrev.com> wrote: >> >>> I thought the OS takes care of that. Are we saying that when saving to a >>> network share this process of creating the semaphore file does not happen? >>> >>> Bob S >>> >>> >>>> On Oct 24, 2017, at 16:01 , Mike Kerner via use-livecode < >>> use-livecode@lists.runrev.com> wrote: >>>> >>>> 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). >>> >>> >>> _______________________________________________ >>> 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." >> > > > > -- > 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 _______________________________________________ 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
