[NILFS users] Permanently delete ("shred") files?
ryusuke at osrg.net
Sun Jun 21 20:39:31 JST 2009
On Sat, 20 Jun 2009 16:43:19 +0100, Will Palmer wrote:
> Hello, and sorry to ask a question which seems to me like something
> which would probably already have been asked, but I didn't see any way
> to search the mailing list archive, and manual skimming of it turned
> up nothing. (in addition, that it wasn't listed in the FAQ or features
> list made me think perhaps it needed to be asked)
Use search box of the top page or
I think you can also use "site" option of web search engines, for
Anyway, questions are welcome.
> Will there be / is there already, a feature to "delete a file
> completely", meaning to remove a single file in such a way that it can
> NOT be restored from checkpoints? Perhaps one which can fill existing
> "versions" of a file with zeros, rather than leaving them as they are?
> While for day-to-day use, being able to go back to five minutes ago
> can often be a godsend, I presume there are more than the handful of
> cases I can think of where "I actually want to leave no trace of that
> file" would be true. Many situations crop up where one can normally
> think "it's okay, I'll just remove the password before I hand it
> over.", but a constantly-logging file-system would default to that not
> being a safe bet. If nothing else, think of the occasional news
> article about someone uncovering supposedly "redacted" sections of
> word documents by viewing history on the file.
I agree. The shred file feature is worthy of consideration.
Since the current nilfs forbids to overwrite any past logs, it would
be realized utilizing GC API. I think it's feasible and sounds
One problem is how we think about identity of the file.
Usually, applications like editor transiently create backup or
temporary files with different names and may change inode number of
the file in process of "save file" operation. These intermediate
files may be snapshotted in checkpoints.
Nilfs internally identify files with inode numbers like regular file
systems, but it is not sufficent for this end. A pathname based
matching method will be required.
And, for the temp file problem, the shred command for nilfs has to
know the pattern of the temp file name for every application. It's
still not infeasible, but the tool ought to have much work to do than
> So I'd expect that it's clear to see it as a necessary feature for
> "desktop use", but is it supported?
Yes, I agree the importance of this feature.
I've added this to the todo items in the site.
More information about the users