Deleting an open file on ramfs(4) can have surpising results. Here's how it's supposed to behave. When a file is removed, the Ram struct which represents the in-memory file has its busy flag reset, so a subsequent i/o will see that it's been deleted.
cpu% ramfs cpu% echo this is x >/tmp/x cpu% { sleep 10; cat } </tmp/x & cpu% rm /tmp/x cpu% cat: error reading <stdin>: file does not exist However, before the i/o takes place, it's possible for another file to be created and re-use the same Ram struct, setting the busy flag again. The process which had the deleted file open is now doing i/o to a different file, without any checks on its permissions, exclusive use flag, etc. cpu% ramfs cpu% echo this is x >/tmp/x cpu% { sleep 10; cat } </tmp/x & cpu% rm /tmp/x; echo actually this is y >/tmp/y cpu% actually this is y A simple fix is to add a reference count to the Ram struct, to keep track of how many Fids point to it, and only allow a Ram to be re-used if both busy==0 and ref==0. The new 9legacy patch ramfs-refcount makes this change. Note to 9front users: don't worry, your ramfs is a completely different program using the 9p(2) library, which doesn't have this flaw. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc364b766ff6473bc-M52976e87f40d78ae095f576e Delivery options: https://9fans.topicbox.com/groups/9fans/subscription