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