Hacker News Reader

Comment by Denvercoder9 | Hacker News Reader

On Linux, it'd likely go until completion. You can't write to executables and libraries that are currently running (ETXTBUSY), so shred can't trash either itself or find.

View on HN

The exception is shared libraries on Linux. Shared libraries are mmapped into the address space of the executable that uses them. Back in the day, mmap used to support a `MAP_DENYWRITE` flag, which it no longer does - so you _can_ write to a shared library that is currently in use. I found this out the hard way when a shared library that I'd written (which maintained some state in its constructor) started crashing mysteriously anytime it was used by more than one process. It took two weeks of debugging to figure out why this was happening. [1] has more details about `ETXTBUSY`, `MAP_DENYWRITE` and shared libraries.

[1] https://lwn.net/Articles/866493/

That doesn't seem right. I can delete nano's executable while it's running, and rm can remove itself.

What am I missing?

rm doesn't actually modify the file. It does an unlink which removes the link from the filename to the file.

Essentially, a file can have 0 or more names linked to it. As long as a file has at least one name or at least one process with it open, it will persevere.

By contrast, shred actually writes to the underlying file.

Ahh, for some reason I completely missed that shred was involved.

True, but I wonder if it would first get stuck on trying to shred e.g. /dev/stderr or if after shredding the files in /etc some daemon woke up and tried to read a file there and choked.

I'd be curious what it did to /sys and /proc

Reply on news.ycombinator.com