Autosaving stacks corrupted on network drives

[Bob Sneidar]

There may be a way to shell the permissions, but it would require sudo on a Mac and UAC on Windows. There is a locked flag in both OS I believe... but you would then have to script saves. An alternative way to semaphore this process is to have a text file that you increment a number for anytime changes are saved, then check to see if the prior number matches the current number and act accordingly. 

But all this really lends itself to the adoption of Trevor's Levure Framework, doesn't it? If the only changes being made are script changes, then set the permission of the UI stack so that only one person or a group of persons can open it for editing, and leave the script only behaviors editable by all. 

Someone can still overwrite someone elses changes though. I was at a SoCal users group some time back, and one of the attendees showed off a very nice commercial app, and they created their own system where files were checked out, including UI files. Otherwise GIT can be used to control access and versioning. 

Bob S


> On Oct 25, 2017, at 11:03 , Ralph DiMola via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> True, The stack is not open after it's read into memory. I can see why/why
> not this is done from a LC point of view. If the stack is being read in from
> a web server it's not possible to lock it. If the file is local/network then
> the stack could remain open and locked for write. Other processes could then
> open/read it but not save it. This looks like it's been around for a long
> time. Could locking stack(s) break existing projects? I vote to lock for
> write any open stacks.
> 
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdimola at evergreeninfo.net