[Top][All Lists]

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

Re: [PATCH] shred: provide --remove methods to avoid excessive syncing

From: Pádraig Brady
Subject: Re: [PATCH] shred: provide --remove methods to avoid excessive syncing
Date: Wed, 20 Nov 2013 00:45:06 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 11/07/2013 11:44 PM, Pádraig Brady wrote:
> On 11/07/2013 10:01 PM, Bernhard Voelker wrote:
>> On 11/07/2013 08:44 PM, Pádraig Brady wrote:
>>> Hopefully the attached addresses this issue.
>> Hi Pádraig,
>>> diff --git a/ b/
>>> index 891b376..6588376 100644
>>> --- a/
>>> +++ b/
>> ...
>>> @@ -9559,12 +9559,25 @@ the whole file.  @var{bytes} can be followed by a 
>>> size specification like
>>> +requiring a sync for every character in every file. This can become
>> minor nit: s/\. /.  /
>> ;-)
> Hah excellent :)
>> The short option doesn't accept the remove methods:
>>   $ src/shred -u unlink x
>>   src/shred: unlink: failed to open for writing: No such file or directory
>> Was this intentional?
> Yes, optional args to short options have many issues.
> thanks for the review!
> Pádraig.

Before I merge this I'd like to understand fully
the reason why shred currently defaults to writing
out progressively shorter names. From the source..

/* Repeatedly rename a file with shorter and shorter names,
   to obliterate all traces of the file name on any system that
   adds a trailing delimiter to on-disk file names and reuses
   the same directory slot.  */

That's doesn't make the reason this method is used obvious
to me at least. So questions...

1. Could anyone expand on the above a bit?
2. If the method is valid, how common is this case it's handling.
If it was a far out edge case we might change the default to --remove=wipe
to be more efficient in the normal case, but keeping in mind that we should
be extra careful about defaults for a tool like shred.


reply via email to

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