Red Hat Bugzilla – Bug 203162
RFE: add option to move files to a given directory rather than delete
Last modified: 2007-11-30 17:11:40 EST
tmpwatch is such a handy little program. It'd be even more handy if I could do
* staged tmpdir cleanup -- tmpwatch 10 days in one directory -> a 20 day
directory -> deleted, allowing a sort of time-based "soft quota" approach
to clearing tmp areas.
* automatically move messages that haven't been looked at in weeks from
my (maildir-format) inbox to a different mailbox.
* simply manage a "workspace" area of active or new files, where old stuff
_probably_ isn't useful anymore but hey there's plenty of disk space so just
stuff it somewhere out of the way in case there's a reason to want it later.
tmpwatch can be replaced by (find ... -atime ... ); using find(1) provides
unlimited flexibility, and tmpwatch shouldn't evolve into a find(1) alternative.
I'm not quite sure where to draw the line; I guess tmpwatch shouldn't be
extended past managing shared storage areas, which eliminates the maildir
Cleaning up /tmp by moving its contents to a different directory doesn't make
much sense for application-created temporary files, the application wouldn't be
able to find the temporary file at the new location.
So this leaves the "shared workspace area" example, including users sharing
files via /tmp. If you really use such setups, adding --move does make sense.
A preliminary implementation of this feature is already half the size of the
other tmpwatch code; the necessary fixing the code to avoid races with symbolic
links (allowing users to place files to directories they ordinarily wouldn't
have access to) would make it even larger.
There are other potential security issues when the temporary directory and the
archive directory are on separate drives, like placing thousands of hard links
to a single large file, or creating a very large sparse file; both are fixable,
but require additional, comparatively large amount of code.
Currently I don't think the feature is useful enough to warrant the added amount
of code and the risk of introducing security vulnerabilities.
In the "shared workspace area" example, it should be quite safe to create a
special unprivileged user and run a (find ... | xargs mv ...) script as this user.