Re: Shred: Add recursion operations [PATCH] (original) (raw)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

From: Eric Blake
Subject: Re: Shred: Add recursion operations [PATCH]
Date: Fri, 09 Dec 2011 11:24:15 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

On 12/09/2011 10:52 AM, Amr Ali wrote:

Hi Eric,

Please don't top-post on technical lists.

I completely agree about the philosophy. But ...

1) I've seen a comment at shred.c:26 that indicates adding -R/-r/--recursive as a TODO.

Hmm, we probably ought to nuke that comment instead, unless there are other implementations of shred that already provide -r.

2) Adding recursion to shred is not bloat, it is in fact enabling shred to do it's job, and to do it well. 3) On the command line, the overhead of first, having to type down all of the find parameters, and second, the overhead of executing shred, quite literally, on every single file is a waste of both time and resources. Adding a simple -r flag, however, enhances usability dramatically compared to the find(1) solution.

You misunderstand 'find -exec shred {} +', which executes as few shreds as necessary to fit within command-line limits. Shred operates on multiple files per pass, and I don't see how teaching shred the ability to recurse adds any noticeable speed over using find to do the recursion. The bulk of your time is spent not in recursion, but in shredding, and using -exec + to avoid fork()ing one shred per file should put the overhead in the noise. Which leaves shred to do one thing well - shredding individual files.

4) It became more than obvious that a lot of users do want such ability if you will, given the amount of postings online that talks/addresses the shred recursion issue.

You didn't post any such links to support your claim. Meanwhile, I can point to the coreutils FAQ: https://www.gnu.org/software/coreutils/faq/#Why-don_0027t-the-utilities-have-built-in-directory-recursion_003f and state definitively that I have used that FAQ less than 5% of the time where the FAQ already provided my answer (my most frequent uses are about 'sort not working' and 'date not working').

5) If find truly is made to enable recursion for all programs, why recursion is available for chmod or chgrp, or the plethora of other tools?

'chmod' and 'chgrp' have recursion because they affect the recursion itself. I can dream up recursion situations where find cannot operate unless you change permissions as you go, but the only way to change permissions as you go is to do one chmod invocation per name, which is inefficient.

'du' and 'ls' have recursion because they output a total - if you were to break things up by command-line length limits, you would have multiple totals.

'rm' has recursion even though 'find -delete' does the same, because 'find -delete' is a GNU extension not required by the standards.

The goal is that if 'find -exec +' can do your task, because no permissions are being modified by your task and your task has no output that would be adversely broken up by multiple max-command-line-length invocations, then your task doesn't need builtin recursion. 'shred' fits this goal, 'chmod', 'ls', and 'rm' do not.

Adding recursion to coreutils is NOT done lightly. You can still manage to convince me that 'shred' fits one of the exceptions I listed above for needing built-in recursion, but the burden is on you to do so, and so far you have not convinced me.

Finally, if you DO manage to convince me, then we would need copyright assignment before your patch could be applied.

-- Eric Blake address@hidden +1-919-301-3266 Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature