On 11/29/10 3:20 AM, Xin LI wrote:
On 11/28/10 20:43, Garrett Cooper wrote:
On Thu, Nov 25, 2010 at 12:14 PM, Xin LIdelp...@delphij.net wrote:
-BEGIN PGP SIGNED MESSAGE-
For certain applications it is sometimes desirable to (e.g. for unix
domain sockets) have file removed when the process quit, regardless
whether the process is quit cleanly. Is there a clean way to do this?
Does it have to be nameless and/or unique?
Not nameless.
Speaking for uniqueness, I think it's unrelated (not good nor bad) for
the use case. The name should be predictable (e.g. can be configured,
so non-child process can find it), though.
How much of a kludge are you willing to live with? :-)
I assume you want to create these files in /tmp. You could create
a subdirectory named something like AutoRM. In that directory,
create a directory by process name. The process could then create
whatever filename it wants in /tmp, and then hard-link that file
to a name under /tmp/AutoRM/pid/fname. So if the process 1242
created /tmp/be_gone, it would also create a hardlink to
/tmp/AutoRM/1242/be_gone . Then some other process could come
along periodically and check all the pid directories in
/tmp/AutoRM. If the process matching some subdirectory does not
exist, the cleanup process would remove the files in that
subdirectory, as well as the matching files under /tmp. So when
process 1242 no longer exists, this cleanup process would see
the file /tmp/AutoRM/1242/be_gone , and then check if /tmp/be_gone
exists and if it's the same inode as /tmp/AutoRM/1242/be_gone .
If so, the cleanup process removes both files. If not, the
cleanup process only removes the file under /tmp/AutoRM/1242.
You'd have to think through the security issues of this setup.
It might be better to have the files under /tmp/AutoRM/pid be
symlinks, and then check that the owner of the symlink is the same
as the owner of the file it points to. At that point you wouldn't
need to have the filenames match, so maybe have name of the symlink
match the name of the inode of the original file.
The nice thing about either of these is that you have to write that
cleanup program just once, and then you can use it for any temp
file created by any process. The files can be named whatever you
want to name them, to keep things easy for other non-child processes
to find the correct temp files. For instance, the process could call
some library routine which it (the process) has no way to modify, but
which returns a filename. Once that library routine returns, the
process could then add the appropriate entry for that filename under
the AutoRM directory.
Still, it is a bit of a kludge. And the files won't disappear
immediately when the process exits. This may not be a great solution,
but it might at least give you some ideas of other ways to approach
the problem.
--
Garance Alistair Drosehn= g...@gilead.netel.rpi.edu
Senior Systems Programmer or g...@freebsd.org
Rensselaer Polytechnic Instituteor dro...@rpi.edu
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
