Re: fgetattr/fsetattr file operation

[Brian Molnar <brian.molnar@gmail.com>]

> On Thu, Jun 4, 2009 at 3:27 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> Can you tell us a bit more about your use case, and how you worked
> around the limitation?

In this FS, when a process opens a file for write mode access, it
maintains its own private copy of the file until it comes time to
close. Upon close, this private copy is "committed" and replaces the
file on-disk. Meanwhile, while the file is open for writing (before
close) the file on-disk remains untouched (both data and metadata).
Thus, any metadata-changing operations that take place against the
file descriptor must only be seen to the process(es) using that file
descriptor. The intended behavior is that an fstat(2) against the file
descriptor will return the attributes corresponding to the
uncommitted, private copy and a path-based stat(2) will return the
attributes of the file on-disk.

To achieve this behavior, the change I made to the FUSE fs code is
such that when a lookup is performed during a file open(2), the file's
dentry is immediately invalidated, so that we essentially get a
'private' dentry and inode, and subsequent path-walks won't find it.
Then when the file is opened, I stuff the file struct pointer into
dentry->d_fsdata. Then when the getattr is called, I check if the
dentry is disconnected and contains a non-null d_fsdata, and if so,
forward it to an fgetattr handler using the file pointer.

The code is deliciously hacktastic, and adds the cost of all these
unnecessary dentry invalidations and lookups. Plus, I haven't even
tested it thoroughly, so I'm sure it's gonna screw up some other
things. The desired approach here is to just cut to the chase and be
able to handle stats made directly to the file descriptor with an
fgetattr operation using the underlying file struct.

Cheers,
- Brian