Re: Shred: Add recursion operations [PATCH]

[Eric Blake]

On 12/09/2011 04:27 PM, Amr Ali wrote:
> Purpose is what drives my modifications towards shred. If you do work on
> multiple files (and that *does* have a high probability), with a simple 
> command
> line regular expression (e.g. './*') you are in fact recursing over files of 
> the
> first level of depth of the current directory node, which conditionally, 
> having
> it recurse on all directory nodes on multiple levels is only an expected
> behavior

If you want to recurse over multiple layers, your first thought should
be to use 'find', not '-r' - by having 'find' at the forefront of your
toolbox, you will be able to solve your recursion issues for a LOT more
tools, not just limited to shred, and in a manner portable to POSIX (and
thus usable on more systems) rather than relying on GNU extensions.

Furthermore, have you not been listening to our arguments that shred on
files is worthless on most modern file systems?  It doesn't destroy data
unless you do it over entire partitions.  Making shred recursive would
be a bad move, because it would give users a false sense of security
(oh, I can shred lots of files in one command line), when in reality,
doing a recursive shred is just disk churn.  If you want lots of files
properly shredded, it is faster, and more reliable, to run something
like 'shred /dev/sdb2' over the entire partition, than it is to try to
recurse over the files on /dev/sdb2 and shred each in turn.  But that
still means you have to plan ahead - if you anticipate needing to shred
lots of files, create a disk partition for those files.

> Before taking a dive at coreutils source code, which was my very first time, I
> always enjoyed just using the *functionalities* it does provide, I knew how 
> they
> do work at very low level details, but this is not the drive behind using 
> them.
> It's simply the desired quantifiable result. The low level technical
> particularities are almost always expected to be abstracted away from usage.

The beauty of free software is that you are free to make your patch, and
use it yourself, even if we don't take it upstream.  I'm glad it was a
positive learning experience for you, even if we don't take this
contribution.  And hopefully you will still find other things to
contribute that do fit in with the coreutils philosophy.

>>
>> Finally, if you DO manage to convince me, then we would need copyright
>> assignment before your patch could be applied.
>>
> Should I use `assign.change.manual`? if so which email I should be sending 
> this
> to, after signing it? That of course if I did convince you.

http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING#n454

Use request-assign.future, and send the initial coordination mail to
assign AT gnu DOT org.  From there, they will help you with the
additional paperwork, and if you are a US resident, it is now possible
to do things electronically instead of snail mail.

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

signature.asc
Description: OpenPGP digital signature