Hacker News Reader

Comment by dredmorbius | Hacker News Reader

"Don't delete, disable" is another key.

Even if I'm doing a mass file delete, if I've got the time for it, first thing I'll do is move/rename the files to a backup / marked-for-deletion directory. Watch for strangeness. Then commit.

If it's site accounts or features, disable them, prevent them from being served, mark them inactive in the database / server. Leave them for a week or two. Then nuke.

Legally proscribed deletions (illegal content, etc.) are another matter, but most other content is eligible for a graduated approach.

View on HN

Luckily, Ning did (does) have a nice way to handle network deletes. Once "retired" it is gone from the system in all visible ways, and then a month later an auto purger comes along to clear database content and blobs for good.

I don't take credit for that -- it was the work of smart folks who came before me. But it sure saved my bacon this time.

I can't upvote this enough. For bonus points, tar the items in question so there's no possibility of access by processes that are holding a file open. If a file is kept open by a process, simply moving it on the same filesystem may not be enough to identify problems.

The advantage of a same-filesystem move (usually to a subdir or alternate directory) is that it's a fast action. You're renaming an inode, not copying data around. When you're dealing with many, or large, files, that's an issue.

(Assuming Linux) If you're concerned with open files, you can do an 'lsof' and screen for files of interest. 'fuser -v filename' will show the process using a file, 'fuser -vk filename' will kill it (xargs or loops for many files, obviously).

And not everything that you're cleaning up is necessarily files, so adapt methods accordingly.

Just to say, moving or tar+removing does not change anything from this point of view. A file will exist until at least one process holds it open. As dredmorbius said, use lsof if this is a concern for you.

Reply on news.ycombinator.com