[Top][All Lists]

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

Re: Shred: Add recursion operations [PATCH]

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:
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

'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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]