How can I test whether a file has been opened for writing in Perl?

Question

In my apps, I need to check whether a given file has been opened for writing for another process, and even this file has been opened my app just skip this file and no "die"-like things will happen here.

---

more detailed description of my problem:

there are two process involved. process A , which is the producer process, process B which is the consumer processw.

process A will create some requests for B to handle and the way he creates request is just create a txt-based file under a certain directory. when A create the request, he dose not know whether B is alive or not, what he needs to do is just drop the request, kind of like write a email to B. after create the request file, A will never visite it again.

prpcess B , is sometime up and sometime down. when it is running, B will "spool" the directory which A drop reqeusts. for each requst file, B just read it hand it and remove it.

but I think there is some race condition there. For example, A just open a file and is on the way of filling up the file with a request and then B want to read the same file and hand it.

my question is how should I hand the race condition gracefully in perl ?

Answer 1

You don't say which OS you're running on. If Unix (or a derivative), take a look at lsof. This will tell you (amongst other things) what files are opened, by whom etc.

Man page here. Note the -F option, which outputs in a fashion suitable for other programs to parse.

Answer 2

Supplementing Brian Agnew's answer: if you would like to use lsof check out Unix::Lsof on CPAN, which provides a perlish interface to the command.

Answer 3

Thanks for the update on your problem. Here's how I would do it:

• Process A opens a temporary file and writes to it. You name the file in such a way that Process B ignores it. You can do that by having it in a temp directory, using a suffix that B doesn't process, or whatever.
• When A is done, it closes the file. The file is now complete, but has the temporary name.
• A renames the file to its final name, which B recognizes as something it needs to process.
• B processes the file.

---

From my previous answer, now explained in the question:

This sounds like a suspicious strategy. Suppose, for instance, that Process A opens File 1 for writing and starts working with it. Process B starts up and considers processing File 1 too. Should it skip it? What if Process A closes the file before Process B can determine if it is open? Should Process B process File 1 again?

It sounds like you have an XY Problem where you are giving us what you think the solution is but not telling us about the problem or task. What are you trying to accomplish or avoid? Something like:

• The same program has many instances processing many files in parallel for the same purpose
• Different programs running simultaneously have to process the same files for different purposes, perhaps in sequence
• The same program might have many instances but only one should update the file (i.e. two people each try to update the same file at the same time).
• Some other situation

Tell us what you are doing and we might be able to solve your problem instead of merely answering your question. :)

Answer 4

This is the sort of thing that file locks are meant to handle, but you probably don't even need to get that low-level. If both ends of the chain are Perl, you should look at using IPC::DirQueue to manage the queue; it's pretty well tested and flexible.