3 ms·
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 itsel
by Denvercoder9 3y ago
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.
- staplung 3y agoTrue, 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.
- yjftsjthsd-h 3y agoI'd be curious what it did to /sys and /proc
- rascul 3y agoThat doesn't seem right. I can delete nano's executable while it's running, and rm can remove itself. What am I missing?
- shric 3y agorm 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.
- rascul 3y agoAhh, for some reason I completely missed that shred was involved.
- mangamadaiyan 3y agoThe 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/ https://lwn.net/Articles/866493/