Bug 203162 - RFE: add option to move files to a given directory rather than delete
RFE: add option to move files to a given directory rather than delete
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: tmpwatch (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
Ben Levenson
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-18 14:01 EDT by Matthew Miller
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-15 19:42:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Matthew Miller 2006-08-18 14:01:47 EDT
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 10:55:51 EDT
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 19:42:54 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.