On Mon, May 16, 2005 at 10:57:57PM +0200, Miloslav Trmac wrote:
> > which isn't always what I want to do. (In fact, usually it's not.) I think
> > the problem is still the one described by Aleksey Nogin in this bug from
> > July, 2000:
> ("This" bug is #14930.)
Oh, sorry -- I meant to include that.
> > Yet, that's marked as fixed in rawhide in August, 2000. Am I missing
> > something? Thanks....
> #91096, I think.
Yep, that's it. Thanks!
> (Using mtime doesn't look safe enough; e.g. a daemon could create a
> "queue" directory and poll it for files added by other processes; that
> can lead to an often used directory with old mtime.)
> Mirek
Or the race condition within a program itself which you mention in the bug.
Although an awfully slow race -- arguably, a daemon shouldn't *expect* that
a directory it created in /tmp yesterday will still be there today. But
yeah, I understand the need for safety here. Unfortunately, it means that
tmpwatch never removes directories.
What about adding an *option* to make tmpwatch do this? I run tmpwatch on my
own ~/tmp, and I can be pretty sure any such race is not going to happen.
Right now, there's no way to say "use atime for regular files, and mtime for
directories", and I think that's a very common desirable case.
It might also be worth mentioning what's going on in the man pages.
--
Matthew Miller mattdm@xxxxxxxxxx <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 74 degrees Fahrenheit.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-devel-list
