Hi Hendrik,

On Mon, May 25, 2015 at 2:25 PM, Hendrik Boom <hendrik@???>
wrote:

> On Mon, May 25, 2015 at 12:29:12PM -0400, Jude Nelson wrote:
> ...
> > What I'm working on going is the following:
> > * fork runfs to create eventfs, a RAM-backed userspace filesystem that
> > looks and smells like tmpfs, but is designed such that (1) files and
> > directories share fate with the process that creates them, and (2) the
> > filesystem remembers the order in which files in a directory are created.
> > We'd use it to implement reliable one-writer many-reader uevent packet
> > multicast. Specifically, the eventfs would work like a tmpfs, but with
> the
> > following different behaviors:
> > -- a directory and its children only exist if the process that created it
> > is still running. Once the process dies, the directory and its children
> > are automatically removed.
> > -- each directory contains an eventfs-managed "head" symlink that points
> to
> > the newest-created regular file child
> > -- each directory contains an eventfs-managed "tail" symlink that points
> to
> > the oldest-created regular file child
> > -- unlink()-ing "head" really unlinks the file that "head" points to, and
> > causes "head" to point to the next-newest regular file child
> > -- unlink()-ing "tail" really unlinks the file that "tail" points to, and
> > causes "tail" to point to the next-oldest regular file
>
> Just wondering what happens if process A creates a directory in
> eventfs, process B makes it its working directory, and then process A
> dies. Does process B end up with a nonexistent working directory?
> umount won't let me do this. WOuld this be different?
>

The directory would continue to exist as long as there was at least one
open handle to it, but subsequent path resolutions on it or any of its
descendants would fail. The effect is basically the same as "rm -rf"-ing
the process's working directory.

Also, like with any other filesystem, you would be unable to unmount it
until all handles were closed.

-Jude