This issue is operating system specific. The path syntax used in your question indicates you are running on some sort of UNIX.
On Linux it is fairly easy if you know the PID that the script is running under. You can interrogate /proc/PID/fd, then follow the links using readlink. Alternatively you can use Linux::Inotify2 to monitor the directory being written to.
On non-Linux UNIX systems iNotify does not exist, and so far as I know many systems do not provide the links in /proc/PID/fd. In those cases you might have to resort to running strace(1) or truss(1) programs (only tracing the open(2) calls) in a pipe then interrogating the output. I have used this method, but it is messy. | [reply] |
Actually, most non-Linux Unix OSses (and even most Linux distros) have at least one of fuser or lsof (the latter stands for 'list open files'...). Of course, to get that information about processes run by a different UID than you currently are, you need root privs.
| [reply] |
fuser is in the POSIX standard, lsof is not.
| [reply]
[d/l]
[select] |
| [reply] |
No, it won't. It will only tell you if a specific file is locked. And only if you have permission to open said file.
| [reply] |
| [reply] |
If both the scripts are run by a common user or if second script is called by root you can see the output of linux command lsof to check the files currently open.
| [reply] |
Since you can get into a whole mess of conditions that are difficult to anticipate (e.g. security, filesystem types, the phase of the moon ...), not to mention race conditions, I have found that the simplest way is simply to attempt to open the file, requesting an exclusive access-mode if you can.
Wrap the whole thing in an eval{} block, then test the error-variable ($@) to see if it has a non-empty value. Also check that the return-code and so forth, but do both.
| |
Hi,
If you are on *nix, you could make a system call to the fuser command.
J.C.
| [reply] |