Not on *nix, and not, as far as I know, on Win32.

I'm afraid that a process might get wedged and lock out all programs using it.

Instead of wrapping a process around flock(), consider using a socket-based lock server, with "locks" recorded strictly in memory. Such a thing can be very simple, and very stable.

Thanks for the tip. I was kind of thinking along those lines when I ran into the dead end with unlink. It's either that or making the script set uid as user lock or something, but then I'll have to wrap up the script in a c program. I guess the big plus with the sockets approach would be the ease of using it over the network albiet at a small performance hit. Whatever I come up with I'll post here.
Thanks!

-Lee

"To be civilized is to deny one's nature."

It's possible, at least on linux, if you don't mind cheating a little.

Find /proc/pid/fd/n, and readlink it. That will give you /a/ (not neccessarly the only) name of the file opened on that fd. (Careful, though, because it will sometimes give things that are not filenames, like socket:n and /foo/bar (deleted).

However, the other ideas on this thread are almost undoubtedly better.

(I know several other unixes have similar proc (or proclike) filesystems, and many of them can probably be used similarly. Win32 doesn't, but you can do internals things to get the names from the handles. I wouldn't recommend it.)

---

We are using here a powerful strategy of synthesis: wishful thinking. -- The Wizard Book

Thats pretty slick... I like it. You can get the same info from /dev/fd/n as well.

% perl -e'open($fh,"/tmp/file"); print readlink("/dev/fd/" . fileno($f
+h))'
/tmp/file
[download]

-Blake

Delete does not follow symbolic links. It deletes the link. So just delete it.

For a symbolic link to be used against you, a directory would have to be removed (or renamed) and replaced with a symbolic link and then your problem could delete a file that has the same basename as the lock file but in the wrong directory. That seems like an unlikely attack with a minor consequence, but you might want to spend a bit of time examining this for your specific situation.

Thanks++ Tye
I just wanted to make sure I wasn't missing something. Our systems have no users that log on from outside the local network except two internal users and root so the chances of anyone even getting in are slim but I'm just trying to dot all the i's and cross the t's.

I do find the server idea interesting though. It makes it easier in theory to coordinate resources across servers.

-Lee

"To be civilized is to deny one's nature."