coreutils
[Top][All Lists]
Advanced

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

Re: [PATCH] Add wipename option to shred


From: Pádraig Brady
Subject: Re: [PATCH] Add wipename option to shred
Date: Wed, 12 Jun 2013 00:36:12 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 06/11/2013 07:20 AM, Joseph D. Wagner wrote:
> Currently, when --remove (-u) is specified, shred overwrites the file
> name once for each character, so a file name of 0123456789 would be
> overridden 10 times. While this may be the most secure, it is also the
> most time consuming as each of the 10 renames has its own fsync. Also,
> renaming may not be as effective on some journaled file systems.
> 
> This patch adds the option --wipename (-w) which accepts the options:
> * perchar - overwrite file name once per character; same as current.
> * once - overwrite file name once total.
> * none - skip overwrite of file name entirely; just unlink.
> If --remove is specified but not --wipename, perchar is assumed,
> preserving current behavior. Specifying --wipename implies --remove.
> 
> In theory, this should provide improved performance for those who
> choose it, especially when deleting many small files.  I am currently
> testing performance on my system, but I wanted to get the ball rolling
> by soliciting your comments and your receptiveness to accepting this
> patch.
> 
> Thoughts?

Thanks for the patch.
While on the face of it, the extra control seems beneficial,
I'm not convinced.  The main reason is that this gives
some extra credence to per file shreds, which TBH are
not guaranteed due to journalling etc.

I see performance as an important consideration when
shredding large amounts of data like a disk device.
However single file performance is less of a concern.
The normal use case for shred would be for single files,
or at the device level. shredding many files is not the
normal use case to worry about IMHO.  If one was worried
about securely shredding many files, it's probably best
to have those files on a separate file system, and shred
that at a lower level.

In any case if you really were OK with just unlinking files
after shredding the data, that can be done in a separate operation:
  find | xargs shred
  find | xargs rm

So I'm 60:40 against adding this option.

thanks,
Pádraig.



reply via email to

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