|Summary:||RFE: add option to move files to a given directory rather than delete|
|Product:||[Fedora] Fedora||Reporter:||Matthew Miller <mattdm>|
|Component:||tmpwatch||Assignee:||Miloslav Trmač <mitr>|
|Status:||CLOSED WONTFIX||QA Contact:||Ben Levenson <benl>|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-10-15 23:42:54 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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.