[Avf-fuse-dev] invisible open files

[Valient G. <vg...@po...>]

I am having trouble supporting the Evolution mail reader from within my
FUSE based filesystem.  The problem is that Evolution makes use of
delete-while-open and rename-over-open file states which are perfectly
valid and documented for Unix, but are not supported in FUSE.

delete-while-open:  a file is opened then deleted (while still open). 
The file is now invisible and could be opened a second time resulting in
a new version of the file with the same name.  The problem supporting
this under FUSE is that libfuse passes the filename as the unique key
instead of an inode, so the userspace program can't disambiguate which
file is being accessed.

rename-while-open:  very similar.  Open "foo", then rename "newfoo" ->
"foo" and open "newfoo".  Now there are two open file descriptors both
referencing a file named "foo", but one is an invisible file.  Evolution
uses this type of operation with its Outbox when sending mail, and
possibly Drafts folder.

There is at least one possibility which would not require much of an
interface change to libfuse.  Since the invisible files are only
accessible via file descriptors and cannot be found in the filesystem,
when an open file is deleted or replaced by another file, libfuse could
emit an internal rename operation.  Since the filename is no longer
important, it could be renamed to any internal value -- just so long as
it is unique within libfuse.  That way hidden files could still be
referenced in an unambiguous way.

So, for example:

system opens "foo", gets file descriptor 1
system opens "bar", gets FD 2
system renames "bar" -> "foo
   fuse sends internal-rename "foo" -> "foo#1" (some random name)
   fuse sends rename "bar" -> "foo" , as it does today
system reads from FD 1
  fuse sends read on "foo#1"
system reads from FD 2
  fuse sends read on "foo"
system deletes "foo"
  fuse sends internal-rename "foo" -> "foo#2"
...

Does that sound reasonable?

regards,
Valient