Bug 203162

Summary: RFE: add option to move files to a given directory rather than delete
Product: [Fedora] Fedora Reporter: Matthew Miller <mattdm>
Component: tmpwatchAssignee: Miloslav Trmač <mitr>
Status: CLOSED WONTFIX QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideKeywords: FutureFeature
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-15 23:42:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matthew Miller 2006-08-18 18:01:47 UTC 
tmpwatch is such a handy little program. It'd be even more handy if I could do
things like:

 * 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.
Comment 1 Miloslav Trmač 2006-08-27 14:55:51 UTC 
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
example.

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.
Comment 2 Miloslav Trmač 2006-10-15 23:42:54 UTC 
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.