The cantmodify property persistence

[PhotoGraphex]

After reading the 'Help' documentation about the cantmodify property, that allows that property of a project to be turned on and off “on-the-fly”, I wonder if after setting it to TRUE and closing the project, does the cantmodify of the project remains to TRUE or should it reverts to FALSE?

I am trying to make projects, used as databases, to be accessible to multiple users over a network, finding a way to 'lock' the projects would make them accessible to all for reading? 

The project could be unlocked for a short moment 'on-the-fly' automatically, by the user's application, when in need for writing! 

Can it work? Would it be a good idea? Is there a better way?

André

[MARK LUCAS]

CantModify isn't a persistent project property - it's just a runtime attribute whose initial state reflects whether SC was able to obtain write permission to the file from the Carbon File Manager when you opened it. If it starts out true then it's also script-settable until the project is closed, but messing with it at runtime doesn't actually change the underlying file system access permission rights in use (just whether SC tries to write to the project).

Unfortunately in the classic Macintosh model SC was designed around write permission is exclusive and obtainable only at file open, so you need to first close a file in whichever app has managed to open it with write access before it becomes possible to obtain write access to it from another (by then opening it afresh, as any existing read-only access rights apps may already have can't be converted into write permission on-the-fly).

Consequently things can't be as simple as multiple copies of SC opening a project simultaneously and then taking turns writing to it by fiddling its cantModify in turn, since that will only be settable in whichever copy managed to obtain exclusive write access first.

Is that what you meant?

-Mark

[MARK LUCAS]

D-OH! Of course that should be 'If it starts out false then it's also script-settable until the project is closed'.

It's tough to get good help these days, ain't it?

;-)

-Mark

[André Tremblay]

Hello Mark

As always, thanks a bunch for your clear and detailed explanations, it will shorten my experimental testing time! 

I should have mentioned that I aborded the cantModify property with a preconception dating back to my time with HyperCard where I was having an xcfn that allowed to check the finder lock status of a stack and to change it if that was possible. If I remember correctly, HC would return an error if a second user would try to open an already opened stack, thus the necessity to lock stacks to make them readable to all users and to unlock the stacks, if possible, just when writing by a user was necessary. 

I should have mentioned also, that in the context of my project, the reading and writing session are extremely short, just the time for instance to run a line like:

local LigneBaDo = line ONE of field ONE of cd CardNumber of project ChHFSBaDo 

or

put item 11 to NbrItems of LigneData into field ONE of cd id CardIDNumber of project ChHFSBaDo

All this is invisible the users. 

If I understand well, in the case of SuperCard, this shouldn't be necessary, as it will be possible for a second user to read from a project while the cantModify property of the project would be TRUE? 

When a user needs to write to a project, the application should check the status of the cantModify property to be FALSE, which mean that the project isn't opened by another user and the DataForkOpen property would be FALSE? 

Should the cantModify property can be only TRUE or FALSE? 

Is it possible for the cantModify property to return ZERO? A result I've seen when a project had been opened from a networked application? Or if a project had been simply checked with the fileBusy function from a networked application. 

Also, is it normal that after a project had been checked with the fileBusy function from a networked application, this project becomes permanently 'busy' and the DataForkOpen property stayed 'OPEN', even after closing the project and even after quitting the application? The only way I found to release the projects is to unmount the networked volume on the computer on which reside the calling application! Which is mostly annoying! 

Well all this according to my observations so far! I wonder why projects stay permanently opened with cantModify property to TRUE after closing the project?

Regards

 

[MARK LUCAS]

On Dec 14, 2022, at 10:37 PM, André Tremblay <andre.t...@photographex.com> wrote:

If I understand well, in the case of SuperCard, this shouldn't be necessary, as it will be possible for a second user to read from a project while the cantModify property of the project would be TRUE? 

SC first tries to open projects with write permission, but if that fails then it silently falls back to requesting read-only permission. I don't know offhand how many simultaneous read-only access paths Carbon permits (though presumably there's some hard limit that varies a bit by system version) as I've never heard of anyone actually running into it, but it's probably enough that you don't need to worry bout it here.

Whichever app instance succeeds in opening a file with write permission exclusively 'owns' the ability to write to the file until they close it again, but any other apps with read-only permission can read it irrespective of whether a write access path to the file exists (however they CANNOT subsequently convert any existing read-only access path they already have to a writable one).

When a user needs to write to a project, the application should check the status of the cantModify property to be FALSE, which mean that the project isn't opened by another user and the DataForkOpen property would be FALSE? 

If you check the cantModify of a project and it reports false, then by definition you've got exclusive write access. How LONG you can retain that for though depends on whether you keep the file open. In other words if you check the cantModify of an arbitrary closed project someplace on disk and it returns false, then at the moment SC reported the status it had managed to secure write access. But if the project wasn't already opened by the current SC instance when you checked its cantModify then by the time you try to open it AGAIN in the next statement write access might prove unavailable.

Thus something like this will NOT reliably do what you seem to want for closed projects:

if not the cantModify of proj someFile then put 123 into cd fld 1 of proj someFile

Instead you'd need to first open the project and THEN test its cantModify to verify that it's currently writable from your app instance. If so write your change and promptly close it. If the project is NOT writable, then take a quick nap and try again. Depending on what each instance is looking to change (and how often), this might or might not work gracefully.

Make sense?

-Mark

[MARK LUCAS]

On Dec 14, 2022, at 10:37 PM, André Tremblay <andre.t...@photographex.com> wrote:

Should the cantModify property can be only TRUE or FALSE? 

I'm not sure I understand the question, but if I do then yes.

Is it possible for the cantModify property to return ZERO? A result I've seen when a project had been opened from a networked application? Or if a project had been simply checked with the fileBusy function from a networked application. 

OK totally lost now. Why would/should cantModify return ZERO, what would it mean/enable, and what do you think fileBusy and the network have to do with this mess?

Also, is it normal that after a project had been checked with the fileBusy function from a networked application, this project becomes permanently 'busy' and the DataForkOpen property stayed 'OPEN', even after closing the project and even after quitting the application? The only way I found to release the projects is to unmount the networked volume on the computer on which reside the calling application! Which is mostly annoying! 

FileBusy doesn't actually open (or even touch) the target project, it just calls the Toolbox FSGetCatalogInfo routine to fetch its file system node info flags from its host volume's catalog tree. These let it report back to SC which forks if any are open, but alas not with what permission.

I wonder why projects stay permanently opened with cantModify property to TRUE after closing the project?

That doesn't sound right. Can you send me a sample (or at least more details/clues)?

-Mark

[André Tremblay]

Hello Mark, 

SC first tries to open projects with write permission, but if that fails then it silently falls back to requesting read-only permission. I don't know offhand how many simultaneous read-only access paths Carbon permits (though presumably there's some hard limit that varies a bit by system version) as I've never heard of anyone actually running into it, but it's probably enough that you don't need to worry bout it here.

Thanks for the confirmation, that's exactly what I was hoping for! In the case of my actual project the probability of two users trying to use the same project simultaneously is very low. 

Whichever app instance succeeds in opening a file with write permission exclusively 'owns' the ability to write to the file until they close it again, but any other apps with read-only permission can read it irrespective of whether a write access path to the file exists (however they CANNOT subsequently convert any existing read-only access path they already have to a writable one).

That's very good, the application in such a case just need to close the project and come back sometime later. 

When a user needs to write to a project, the application should check the status of the cantModify property to be FALSE, which mean that the project isn't opened by another user and the DataForkOpen property would be FALSE? 

If you check the cantModify of a project and it reports false, then by definition you've got exclusive write access. How LONG you can retain that for though depends on whether you keep the file open. In other words if you check the cantModify of an arbitrary closed project someplace on disk and it returns false, then at the moment SC reported the status it had managed to secure write access. But if the project wasn't already opened by the current SC instance when you checked its cantModify then by the time you try to open it AGAIN in the next statement write access might prove unavailable.

Thus something like this will NOT reliably do what you seem to want for closed projects:

if not the cantModify of proj someFile then put 123 into cd fld 1 of proj someFile

Instead you'd need to first open the project and THEN test its cantModify to verify that it's currently writable from your app instance. If so write your change and promptly close it. If the project is NOT writable, then take a quick nap and try again. Depending on what each instance is looking to change (and how often), this might or might not work gracefully.

Make sense?

Very much indeed, it dots the i's and crosses the t's, it addresses a question I was wondering about for a while! I'll make sure to follow correctly the principle of this procedure: 

open invisible project HFSProjPathName

if the cantmodify of project HFSProjPathName is FALSE then put NewContent into field ONE of cd CardNumber of project HFSProjPathName

close project HFSProjPathName

I suppose that checking the result after opening would add a layer of safety. Very good! 

----------

Should the cantModify property can be only TRUE or FALSE? 

I'm not sure I understand the question, but if I do then yes.

Is it possible for the cantModify property to return ZERO? A result I've seen when a project had been opened from a networked application? Or if a project had been simply checked with the fileBusy function from a networked application. 

OK totally lost now. Why would/should cantModify return ZERO, what would it mean/enable, and what do you think fileBusy and the network have to do with this mess?

Well, your puzzelment does answer my question! That's the reason I made the following experiment, having occasionally some projects that are stuck 'busy' with no way to regain a writable access; even when all SC applications have quitted over the network, than to turn off the AFP and SMB protocol over the network and sometime to reboot the computers to make the projects writable again! So far my best clue is that those projects were accessed by a remote SC standalone over the network! 

Also, is it normal that after a project had been checked with the fileBusy function from a networked application, this project becomes permanently 'busy' and the DataForkOpen property stayed 'OPEN', even after closing the project and even after quitting the application? The only way I found to release the projects is to unmount the networked volume on the computer on which reside the calling application! Which is mostly annoying! 

FileBusy doesn't actually open (or even touch) the target project, it just calls the Toolbox FSGetCatalogInfo routine to fetch its file system node info flags from its host volume's catalog tree. These let it report back to SC which forks if any are open, but alas not with what permission.

I understand and agree, I wonder if this might lead to the issue reported above! 

I wonder why projects stay permanently opened with cantModify property to TRUE after closing the project?

That doesn't sound right. Can you send me a sample (or at least more details/clues)?

Here are my methodology and main observations:

A - The server is a MacPro 2013 running MacOS High Sierra, the server application is a SC standalone made from SC483.b3 2022-08-10 11_26_17 Engine.plugin

B - This user is MacPro 2013 running MacOS Mojave, the user application is SuperCard Suite 4.82b3

C - This user is MacMini 2012 running MacOS Mojave, the user application is a SC standalone, the same as A

The network is gigabit ethernet and the projects' volume are mounted with SMB protocol for B and C. The projects are on a local volume for A. 

If I do in order the following steps, 

1 - On A, if I query in msg: answer filebusy(HFSProjPathName) -> DataForkOpen = false, ResForkOpen = false, AnyForkOpen = false

2 - On B or C, if I query in msg: answer filebusy(HFSProjPathName) -> DataForkOpen = false, ResForkOpen = false, AnyForkOpen = false

3 - On A, if I query in msg: answer filebusy(HFSProjPathName) -> DataForkOpen = true, ResForkOpen = true, AnyForkOpen = true

During those three steps I didn't open or close the project HFSProjPathName. 

I can possibly do more tests with other computers and systems, but these are the ones with the MacOS of interest. 

----------- 

With the same hardware, with a different project:

1- On A: if I query in msg: answer filebusy(HFSProjPathName) -> DataForkOpen = false, ResForkOpen = false, AnyForkOpen = false

2 - On B or C, in msg: 

open project HFSProjPathName

close project HFSProjPathName

3 - On A, if I query in msg: answer filebusy(HFSProjPathName) -> DataForkOpen = true, ResForkOpen = false, AnyForkOpen = true

or if I query in msg: the cantmodify of project HFSProjPathName -> TRUE

4 - On B and C, I quit both users' applications. 

5 - On A, if I query in msg: answer filebusy(HFSProjPathName) -> DataForkOpen = true, ResForkOpen = false, AnyForkOpen = true

or if I query in msg: the cantmodify of project HFSProjPathName -> TRUE

-------

So far these are my observations, I'll try to see if I can gather more informations and clues!

Thank you so much for your help!

André

[MARK LUCAS]

On Dec 15, 2022, at 9:42 PM, André Tremblay <andre.t...@photographex.com> wrote:

The network is gigabit ethernet and the projects' volume are mounted with SMB protocol for B and C. The projects are on a local volume for A. 

In my testing here SMB appears to be the proximate cause of the glitch - if I unmount everything and then switch File Sharing back to use AFP (in System Prefs->Sharing->Options) at both ends then FileBusy seems to work as expected again.

Unfortunately I wouldn't be surprised if sharing APFS volumes over AFP isn't supported though, but that may not be an issue for you.

Can you check whether this is feasible (at least temporarily on two or more of your systems) and if so whether it has any effect on the problem?

In the meantime I'll keep trying to figure out another way to skin this cat…

Thanks,

-Mark

[André Tremblay]

Hello Mark,

Le 16-déc.-2022 à 16:01:13, 'MARK LUCAS' via SuperCard Discussion <superca...@googlegroups.com> a écrit :

In my testing here SMB appears to be the proximate cause of the glitch - if I unmount everything and then switch File Sharing back to use AFP (in System Prefs->Sharing->Options) at both ends then FileBusy seems to work as expected again.

You beat me on speed, I was also suspecting the SMB protocol may cause the issue!

Unfortunately I wouldn't be surprised if sharing APFS volumes over AFP isn't supported though, but that may not be an issue for you.

It isn't an issue! 

Can you check whether this is feasible (at least temporarily on two or more of your systems) and if so whether it has any effect on the problem?

After unmounting the projects' volume that was SMB mounted and mounting it again with AFP, it also seems to me that filebusy() isn't grabbing the project anymore! 

I'll make further tests, but so far so good!

In the meantime I'll keep trying to figure out another way to skin this cat…

Thanks a bunch!