it works in traditional Unix because files are really i-nodes and the directories refer to them, but even if the count is zero, they survive until a separately reference-counted in-memory copy made by iget loses its final open-file reference. unless the system crashes before that event. oh no!
On Wed, 28 Jan 2026 at 23:14, Charles Forsyth <[email protected]> wrote: > > "Filesystem filesystems" on Plan 9 mimic Unix's "unlink, not delete" >> behaviour. > > > venti/fossil doesn't, and it's not a requirement. > > h% file blimp > blimp: cannot open: 'blimp' file does not exist > h% echo still here >blimp > h% {sleep 10; cat}<blimp& > h% rm blimp > h% cat: error reading <stdin>: file has been removed > > On Wed, 28 Jan 2026 at 20:42, Stuart Morrow <[email protected]> > wrote: > >> > When a file is removed in 9front using rm, I take it that it is >> altogether deleted and non-recoverable. In Linux one can sometimes use >> specialised tools to recover files removed with rm. >> >> It's not clear to me what exactly you're asking. The last sentence >> seems to narrow it down, but in fact doesn't, because you might be >> referring to the 'cat /proc/.../fd' method on a living process that >> still has the file. >> >> "Filesystem filesystems" on Plan 9 mimic Unix's "unlink, not delete" >> behaviour. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T0c7edd96d131231e-Mc6e6bb88ee967e0b6c119947 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
