>A better approach in my mind would be to move the orphaned inodes to >an invisible directory whose contents are automatically deleted at the >next mount (by the mount utility or the kernel). The kernel could also >wipe them when the last reference is closed, but only if the device is >mounted for write still.
Can't unmount a device with processes executing off of it. I believe DNIX could. >the general semantics for deleted open files are important to security DNIX did this, not on a file being deleted necessarily, but also on it being opened for write. And it _only_ did this for executing images, anything being used as a regular file continued to behave as before. Basically it noted whenever it could no longer rely on the original executable file to feed the in-memory execution cache, and arranged to move the contents to a private place that it _could_ rely on, releasing the original reference. It worked pretty slick. Want to get a new program? Cp or tar it, no special precautions. Want to force a resident program to start using the new version? Then restart it. -- Jim _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
