0

In case I have a program that needs some basic configuration files that cannot be modified when it is running (during start-up), what is the proper way to implement a lock in its directory environment?

Details:

The scenario I'm thinking is: only the software itself is able to modify the files. So, I need to protect the environment from other instances of the software. The software also might be composed of several different programs. So, I need to find an interface that is straightforward to share among processes.

Idea 1:

One way would be acquiring lock (flock) for each configuration file. This is nearly impractical to implement and maintain.

Idea 2:

The second way I've been thinking is to create a .lock file in my directory during start-up and delete it when the config files are safe to be modified. I've seen many commercial softwares using some similar approaches. However, I suspect that the lack of atomicity of these operations might be an issue. Is this method safe when several applications might concurrently try to create/poll/delete the lock file?

rph
  • 901
  • 1
  • 10
  • 26
  • I suppose Linux env. If applicable you should take a look a at [mandatory-locking](https://www.kernel.org/doc/Documentation/filesystems/mandatory-locking.txt) – LPs Aug 29 '16 at 06:52
  • You can `flock` a directory so it doesn't have to be per config file. Or you can even `flock` a single special file before accessing any config file. – kaylum Aug 29 '16 at 06:53
  • @kaylum Thanks. I've been thinking about this solution. But I'm facing troubles about sharing the lock priveledges with other processes. During startup, several programs might launch. So, sending the file descriptor or lock descriptor through some IPC seems not that easy. – rph Aug 29 '16 at 06:57
  • 1
    You can think about a file-manager-process that serialize actions on those files. Obviously it is a bottleneck for the IPC flow. – LPs Aug 29 '16 at 06:59
  • @LPs That looks like an interesting way. One manager that is responsible to launching instances of the software. In this way, I would have control over their progress and grant permission to continue. – rph Aug 29 '16 at 07:03
  • If you're not confident about lock files, maybe a lock directory will work instead; that is atomic (that is, only one process can successfully use `mkdir()` to create the lock directory, even if running with root privileges). – Jonathan Leffler Aug 29 '16 at 07:06
  • @JonathanLeffler I think the issue is not in the atomicity of single operations such as mkdir(). Instead, the two phases: (1) test if dir exists and (2) create directory if not, as a whole, have to be atomic to guarantee exclusiveness. Pretty much like the atomic operation CAS (Compare and Set) to implement thread-locks. – rph Aug 29 '16 at 07:10
  • 1
    @rkioji: You don't test whether the directory exists; you try to create the directory and if it fails because the directory exists, then you know something else is using it. This is the difference between [LBYL and EAFP](http://stackoverflow.com/questions/404795/lbyl-vs-eafp-in-java/) — in this context, LBYL is wrong/bad and EAFP is correct. Or, more accurately, even if you LBYL, you still have to deal with the possibility of failure because someone else also looked and leaped before you did — the looking was pointless in the first place. – Jonathan Leffler Aug 29 '16 at 07:14
  • @JonathanLeffler I think this pretty much answer my question. Seems very straightforward. – rph Aug 29 '16 at 07:19

0 Answers0