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

[Pádraig Brady]

On 11/20/2013 06:57 AM, Bernhard Voelker wrote:
> On 11/20/2013 01:45 AM, Pádraig Brady wrote:
>> 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 sounds like the filesystem terminates the file name on disk,
> e.g. with a NUL character, i.e. during each rename() the last
> character gets overwritten so that all characters in the original
> name are changed to the terminating character:
> 
>   's',  'e',  'c',  'r',  'e',  't', '\0'
>   's',  'e',  'c',  'r',  'e', '\0', '\0'
>   's',  'e',  'c',  'r', '\0', '\0', '\0'
>   's',  'e',  'c', '\0', '\0', '\0', '\0'
>   's',  'e', '\0', '\0', '\0', '\0', '\0'
>   's', '\0', '\0', '\0', '\0', '\0', '\0'
> 
> (Just a guess, of course.)

So that's what I inferred from the original comment above,
but then thought, why don't you just rename to the same size
to overwrite everything in one go.  But I realize now that
that would leak the length of the original file name.

Now you could infer the size (with a little inaccuracy due to alignment 
padding),
given other patterns in the directory (like the inode number for example),
so this scheme would only really help I think where one has fixed sized
directory entries, which would not be the norm.

I'll stick with the current patch for now,
with some comments/docs about the length consideration.

thanks,
Pádraig.