tmpwatch and removing directories....

[Matthew Miller]

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 at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>
Current office temperature: 74 degrees Fahrenheit.