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.