Issue #2910 has been updated by Peter Couvares.
That would be better -- but honestly, I think it's exceedingly unlikely anyone would specify a directory, even without matches, and not expect it to tidy the immediate contents of that directory. Tidying up files in a directory (e.g., based on file modification time) is a very, very common use-case (/tmp being the obvious example). In contrast, tidying a directory with recurse=0 makes almost no sense in any scenario. What could it mean? Either a noop, which by definition no one would intend to specify, or else a request to remove the directory itself, which seems highly unusual (and only makes sense if it's empty -- otherwise it's still a noop). I tend to be quite conservative in these sorts of matters, erring on the side of not deleting things -- but in this case the feature is *for* deleting things and recurse=0 fails to accomplish that. I think users will want and expect tidy to recurse=1 on a directory (even without matches) and will be very surprised if it doesn't. However, if you disagree, please throw an error if recurse is unspecified for a directory rather than making it a silent noop. Special-casing the matches attribute doesn't make much sense since others like age might be used instead. Regardless of what you decide, I appreciate the time and thought you're putting into solving this. Thanks! ---------------------------------------- Bug #2910: tidy failing to remove any matching files http://projects.puppetlabs.com/issues/2910 Author: Peter Couvares Status: Needs design decision Priority: High Assigned to: James Turnbull Category: tidy Target version: 0.25.5 Affected version: 0.25.4 Keywords: Branch: I'm somehow unable to get tidy to work _at all_ -- here is what I'm specifying, right inside a node definition in nodes.pp: <pre> tidy { tidy_tmp: path => "/tmp/", age => "7d", backup => false, matches => [ "jna*.tmp" ], } </pre> The rest of my node definition, and everything else in nodes.pp more generally, works fine -- but matching files are not being tidied. I can confirm many matching files on the client host in question with: <pre> find /tmp -maxdepth 1 -name 'jna*.tmp' -atime +7 -print </pre> I've tried the following in turn, with no luck: * removing the matches attribute altogether, * removing the age attribute altogether, * replacing the matches list with a simple string, * removing the explicit path attribute and using "/tmp" as the name, * and setting the type attribute to "mtime" instead of the default atime. I'm out of ideas, no one on IRC had any other ideas, and so I now suspect a bug. If I'm doing something foolish, however, I'd be grateful to know. Thanks. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
