lucamar
That a makes certain sense, if the file doesn't exists. FileExists() uses a call to fpAccess(), which will fail (and set the error) if the file doesn't exists.
i see that baseunix unit is loaded with -vu so fpaccess must give faster code then using fileexists
(didn't know about fpaccess)
--
Regarding multiple locks/unlocks, man 2 flock has this to say:
Quote from: Linux Programmer's Manual - FLOCK(2)
A process may only hold one type of lock (shared or exclusive) on a file. Subsequent flock() calls on an already locked file will convert an existing lock to the new lock mode.
thanks didn't know about flock so found these
https://www.gnu.org/software/libc/manual/html_node/File-Locks.htmlhttps://gavv.github.io/articles/file-locks/man 2 fcntl
so fpfcntl would be better then using fpflock cause it affects the file descriptors themselves (in /proc?)
--
That's not exactly true: there are quite some conditions (one of which is if the file is already locked by other process) in which flock() will return -1, which indicates an error, or simply not return (if you didn't use LOCK_NB) until the file is unlocked.
It's important to note that flock() is an advisory lock, not a forced one; any other process may decide to blithely ignore it and read/write from/to the file without the system trying to impede it. It's alright for what you're using it (preventing simultaneous usage by multiple instances) but it's not a "real" system-level lock.
yes i can see that echo "distrupt file" >> test.txt shows it isn't locked just locked against other fpc file access and looks like c also doesn't abide by fpc's fplock!!
--
i am confused by LOCK_NB if it isn't blocked then don't i have to put the check 'result is not -1' in a loop?
that is what paritally made using fileopen( fmShareExclusive) so slow
--