[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 11:34:05 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
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.