Understanding `mkpidlock` and why it deletes my files

General Usage
1

I have multiple instances of a script that will need to write on a single file, so I was looking into locking the access to said file by using mkpidlock. Eventually I’ll want to use it with HDF5 files (which I know I can’t with mkpidlock as it is) so I’m trying to understand its inner workings.
I think there’s something fundamental I’m not understanding, since the following behaviour surprises me:

  1. Create a plain text file, echo "hello" > test.txt
  2. Start Julia, loading the function: julia -ie 'using FileWatching.Pidfile: mkpidlock'
  3. Open the file with it, but without doing anything with it:
mkpidlock("test.txt"; stale_age=2, wait=true, mode=0o666) do
       () -> nothing
       end

The do block executes after some seconds, warning me that it’s attempting to remove a probably state pidfile. I find it odd, since I just created it.
The most surprising thing is however that after the do block ends the file just disappears. I though I did nothing on it! What happened?
I dug into the code for mkpidlock and found out that a likely culprit is the tryrmopenfile called by open_exclusive, in FileWatching/src/pidfile.jl, but I don’t understand why the file should get deleted. And also the reason for the initial waiting period in the first place. What am I missing here? Is the function erasing the file I created because there was a stale pidfile?

2

I had the same problem and came to the conclusion that mkpidlock() is not supposed to lock the file passed as first argument. Rather, it creates a file that acts as a lock. The fact that the file exists signals other processes that the lock is already taken by someone. I think the reason behind this is that it is very difficult to implement a cross-platform file lock for Linux, Windos, MacOS, etc. So we should use it like so:

mkpidlock("test.txt.lock") do
    open("test.txt", "a") do io
        write(io, "Meow")
    end
end
2 Likes