How do I atomically create a locked file in Linux?

Question

Scenario: I have many processes running that need to fetch files over the net. If the file is already downloaded, I want it cached on disk. If another process is downloading the file, block until it is finished downloading.

I've been trying to find the easiest way to do to this. The obvious way is to:

create file w/ an exclusive lock active on it only if it doesn't exist (O_CREAT | O_EXCL)
if file exists already:
   open file and acquire exclusive lock
else:
   download to newly created file
release lock

This system accomplishes the above goals with (seemingly) no race conditions

Unfortunately, I couldn't find documentation on how to use open(), etc. to create a file that is locked in Linux. If I split the create step into:

open w/ O_CREAT | O_EXCL
flock

a race condition now exists between the create and lock (non-creating process acquires the lock before the creator does).

I realize I could use an external lock file per file (e.g. filename + '.lock), which I acquire before attempting to create filename, but this feels.. inelegant (and I need to now worry about how to files that actually have a .lock suffix!)

Is there anyway to atomically create and lock it (as Windows offers) or is the external lockfile method pretty much what is standard/required?

Liverish

Answer 1

The race exists anyway. If the file may or may not exist then you have to test for its existence before trying to lock it. But if the file is your mutex, then you can't possibly do that and the space between "if file exists already" (false) and "download to newly created file" is unconstrained. Another process could come by and create the file and start downloading before your download begins, and you would clobber it.

Basically don't use fcntl locks here, use the existence of the file itself. open() with O_CREAT and O_EXCL will fail if the file already exists, telling you that someone else got there first.

Nestling

I'm not sure how the race would exist if I could atomically create a locked file only if the file does not exist. (condition is also atomic). O_CREAT | O_EXCL is an atomic create if file doesn't exist; I just want to do that with a lock. Another process can't start downloading as it will detect the file exists. Finally, I can't use open alone as I must block until the download is done; in my solution, I rely on the (exclusive read/write) lock. – Liverish

You're right, atomically creating and locking a file would fix your problem. But that's not the way fcntl locks work, sorry. If you want to use a fcntl lock, the file your are locking has to exist before any synchronization action is taken by your program. Find a way to move the creation outside that if() in your pseudocode, or else work up another synchronization protocol that doesn't use the download file as the mutex. – Nestling

Got it, so the answer is that Linux doesn't offer Windows style atomic locks with opening. I'll stick with the lockfile method. – Liverish

Answer 2

Why don't you use a lockfile utility?

Examples

Suppose you want to make sure that access to the file "important" is serialised, i.e., no more than one program or shell script should be allowed to access it. For simplicity's sake, let's suppose that it is a shell script. In this case you could solve it like this:

...
lockfile important.lock
...
access_"important"_to_your_hearts_content
...
rm -f important.lock
...

Burck

Answer 3

I'm struggling with how to solve a similar problem at the moment, which is what brought me to your question. As I see it, the essence is:

int fd = open(path, O_CREAT|O_RDWR|O_EXCL, mode);
if (fd == -1)
    {
    /* File already exists. */
    the_file_already_exists(fd);
    }
else
    {
    /* I just now created the file.  Now I'll lock it. */

    /* But first I'll deliberately create a race condition!! */
    deliberately_fork_another_process_that_handles_file(path);

    int code = flock(fd,LOCK_EX);
    if (code < 0)
        {
        perror("flock");
        exit(1);
        }

    /* I now have the exclusive lock.  I can write to the file at will --
    or CAN I??  See below. */
    write_to_the_file_at_will(fd);
    }

Obviously in real life I would never deliberately create that race condition, but its equivalent could certainly happen by accident in a real system. That other process might, for example, open the file for reading, obtain a shared lock on it, and read the file. It would see an empty file. That could mean that a write operation is in progress, but it might mean that the file is simply empty and that's the correct and final answer.

If empty files are not allowed, the reader could simply behave exactly the way it would behave if the file was missing. After all, if the reader had started a millisecond earlier it would have failed to open the file anyway. In this case the reader needs to check if the file is empty after it opens it.

If empty files ARE allowed, then you're in a bit of a quandary and I have no ready answer for that.

The problem I have is that when a file is first created, I want to write some sort of default value into it, because I want to "auto-initialize" a fresh system without having to pre-create every possible file it might need. That other process handling the file might itself have already initialized it! For all I know, three other processes might have also run in the meantime and altered the value. In that case I certainly do not want to "write to the file at will" after obtaining the exclusive lock, because I will clobber all those changes.

I suppose the answer is for my code above to ensure that the file is empty before writing to it. If it is NOT empty, then the code should behave exactly as if the file already existed: i.e., it should call:

the_file_already_exists(fd);

Perhaps the bottom line to all of this discussion is that every process which handles the file in any way should check to see if it is empty and behave accordingly. Again though, if empty files ARE allowed, then I can't yet think of any guaranteed solution. None of this would be necessary if there were some way to create the file and lock it as a single atomic sequence, but I don't think there is any way to do that.

Nose

One small point: it is possible to lock the parent directory itself. Just open the directory read-only just like any other file and get the exclusive lock on that handle. As long as everyone is playing by the rules, you can now create and delete files however you wish while you have the lock. The downside is that locking the parent directory is less granular than locking individual files. – Nose