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 16:56:19 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

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

Attachment: signature.asc
Description: OpenPGP digital signature