[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/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.