Path: utzoo!utstat!helios.physics.utoronto.ca!jarvis.csri.toronto.edu!rutgers!iuvax!maytag!looking!brad From: brad@looking.on.ca (Brad Templeton) Newsgroups: news.software.b Subject: Re: Dynamic "smart" expiration? Message-ID: <68713@looking.on.ca> Date: 29 Dec 89 04:50:57 GMT References: <1989Dec27.033817.9953@smsc.sony.com> <1989Dec28.063932.13720@robohack.UUCP> <1989Dec28.171830.13130@smsc.sony.com> <1989Dec29.020109.16829@utzoo.uucp> Organization: Looking Glass Software Ltd. Lines: 31 Class: discussion I found using the size of a file as a parameter to be useful. My expire assigned a score to each article. The base of the score was the age of the file in seconds (I ignored any explicit expiry date -- I didn't want outsiders deciding how long their pearls of wisdom would stay on my system when I only had 3000 blocks free, thank you.) In any group, one could add to the score based on the group, so that some groups hung around longer than others. In addition, I did set it so that the size of the file (multiplied by a constant of your choice) was added to the score. The scores were then sorted, and the files with the highest scores were removed until enough disk space had been freed -- or rather until the remaining disk space was my fixed allocation for news. Adding the size made it the case that one really big article would go instead of a dozen small ones. This kept the average number of days of articles kept higher than it would have been otherwise. So Henry, there's one point of data. I would post this very simple expire here if people want it -- it's quite short -- but there's a lot it doesn't do. For one, it ignores the history file all together, and just gets ages from stat(). It doesn't update the database or the active file. That means you need to run expire -rebuild every few days to get things back in mesh. This program controls the disk space problem and lets the real expire keep track of the databases and active file. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473