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.
