• John Muir's avatar
    FUSE: Notifying the kernel of deletion. · 451d0f59
    John Muir authored
    Allows a FUSE file-system to tell the kernel when a file or directory is
    deleted. If the specified dentry has the specified inode number, the kernel will
    unhash it.
    
    The current 'fuse_notify_inval_entry' does not cause the kernel to clean up
    directories that are in use properly, and as a result the users of those
    directories see incorrect semantics from the file-system. The error condition
    seen when 'fuse_notify_inval_entry' is used to notify of a deleted directory is
    avoided when 'fuse_notify_delete' is used instead.
    
    The following scenario demonstrates the difference:
    1. User A chdirs into 'testdir' and starts reading 'testfile'.
    2. User B rm -rf 'testdir'.
    3. User B creates 'testdir'.
    4. User C chdirs into 'testdir'.
    
    If you run the above within the same machine on any file-system (including fuse
    file-systems), there is no problem: user C is able to chdir into the new
    testdir. The old testdir is removed from the dentry tree, but still open by user
    A.
    
    If operations 2 and 3 are performed via the network such that the fuse
    file-system uses one of the notify functions to tell the kernel that the nodes
    are gone, then the following error occurs for user C while user A holds the
    original directory open:
    
    muirj@empacher:~> ls /test/testdir
    ls: cannot access /test/testdir: No such file or directory
    
    The issue here is that the kernel still has a dentry for testdir, and so it is
    requesting the attributes for the old directory, while the file-system is
    responding that the directory no longer exists.
    
    If on the other hand, if the file-system can notify the kernel that the
    directory is deleted using the new 'fuse_notify_delete' function, then the above
    ls will find the new directory as expected.
    Signed-off-by: default avatarJohn Muir <john@jmuir.com>
    Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
    451d0f59
dev.c 46.3 KB