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

[Pádraig Brady]

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/THANKS.in b/THANKS.in
>>> index 891b376..6588376 100644
>>> --- a/THANKS.in
>>> +++ b/THANKS.in
>> ...
>>> @@ -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/\. /.  /
>> http://xkcd.com/1285/ ;-)
> 
> 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.

thanks,
Pádraig.