With Linux you would make the file immutable but that requires extra acl's other than the regular rwx properties. I would be interested if you could do the same with files under AmigaOS.
Maybe behaviour of write and delete flags should be changed. If file is write protected (protected against modification) renaming it shouldn't be allowed either (because renaming a file is one way to modify it). And if it's delete protected moving it shouldn't be allowed (because moving it basicly requires deleting it from the source).
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
I believe Lock()ing a file only prevents it from being deleted
Did you try? What I experienced with locked files is that I can neither move nor delete nor rename them (which is what makes sense at most in the meaning of "locked", anyway), so all your wishes come true at once.
Just to add some info about locking of files on os4 and to lock() (i think):
Usually when i compile some binary, and it crashes, and i still have GR window alive , i can't write to the same file again, because file is locked.
But its enough just to rename binary to anything else, and rename will works fine, and i can again create a binary with the same name as it was before.
So i can think about 2 moments:
1. maybe that lock() not prevent file to rename (not real lock then)
Did you try? What I experienced with locked files is that I can neither move nor delete nor rename them (which is what makes sense at most in the meaning of "locked", anyway), so all your wishes come true at once.
It has been my extensive experience with AmigaOS that locked files can be renamed & moved... however I double-checked, and that does appear to be the case. The main reason for saying "I believe" is I didn't know if there was some trick that could make lock() do what I want.
@broadbandblues Quote:
You can stop it from being opened with an exclusive lock but the user can rename the locked file.
Why would you want too?
The file is REQUIRED for the program to operate correctly. My fake-threading implementation for C++ (which works-around the fact that exceptions cause multi-threaded C++ programs to die horribly on AmigaOS) needs it's executable file to not be moved or renamed, so that it can still find it after the program has been started.
IDEA: Having lock()ed the file, which prevents deletions, I wonder if I can correctly tell where the file is after the user has moved/renamed it? That could be a work-around...
The file is REQUIRED for the program to operate correctly. My fake-threading implementation for C++ (which works-around the fact that exceptions cause multi-threaded C++ programs to die horribly on AmigaOS) needs it's executable file to not be moved or renamed, so that it can still find it after the program has been started.
IDEA: Having lock()ed the file, which prevents deletions, I wonder if I can correctly tell where the file is after the user has moved/renamed it? That could be a work-around...
so the program needs to find itself? and it has a lock on 'itself'?
@broadblues I wasn't certain whether NameFromLock() would provide the correct information after a locked file was moved, but it does seem to. So problem solved :)
In this very unlikly case, can't you have that CreateNewProc stub simply fail with a NULL return code, just as any failed attempt at starting a process?? I mean, it could also be that this newly started copy would also fail because of lack of memory or anything.
Most processes are started right at program start anyway and won't have this problem. But if NameFromLock really works then that's great!
Locking from renaming (which thankfully seems impossibly) would also make it difficult to develop since a crashed instance cannot be compiled again because "text file is busy".
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
Most processes are started right at program start anyway and won't have this problem
Not in the case of my PictureAlbum program: When-ever the window becomes inactive/active it uses my 'std/cGfx' module to disable/enable the window vsync (along with associated video buffer, which thus saves video memory), and a side-effect of this is that it's vertical-blank-watching thread gets disabled/enabled.
I noticed this when I started recompiling it (which deletes the executable) while it was still running, and then reactivating the window caused it to crash. The same would happen if it was renamed/moved, but luckily the work-around is fairly easy
Quote:
can't you have that CreateNewProc stub simply fail with a NULL return code, just as any failed attempt at starting a process??
It should have done that, and an exception should get thrown in that case... but for whatever reason that leads PictureAlbum to crash (it's certainly a rather unexpected situation to have to deal with).
It should have done that, and an exception should get thrown in that case... but for whatever reason that leads PictureAlbum to crash (it's certainly a rather unexpected situation to have to deal with).
Not being able to start a process should not be an unexpected situation IMO, rather it should be expected just like being out of memory, especially considering the size of PE (C++) executables.
Anyway, sounds like you're figuring it out :)
Another thing that just struck me with this technique: Isn't there a pretty noticable delay relaunching the entire app rather than executing a plain function when starting and stopping the process in runtime?
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
~Yes I am a Kiwi, No, I did not appear as an extra in 'Lord of the Rings'~ 1x AmigaOne X5000 2.0GHz 2gM RadeonR9280X AOS4.x 3x AmigaOne X1000 1.8GHz 2gM RadeonHD7970 AOS4.x
Another thing that just struck me with this technique: Isn't there a pretty noticable delay relaunching the entire app rather than executing a plain function when starting and stopping the process in runtime?
You would have thought so, but that does not seem to be the case! If it did ever turn out to be the case, then I could fairly easily stop it from happening (it would just complicate the code).
You would have thought so, but that does not seem to be the case! If it did ever turn out to be the case, then I could fairly easily stop it from happening (it would just complicate the code).
Still, for simple things with high frequency creating/destroying one could just use the old normal way while just be aware of the issue with exceptions.
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
