[fuse-devel] [Fwd: Re: gvfs & FUSE...]

[nf2 <nf...@sc...>]

Hi all,

Alexander Larsson has allowed me to forward this private discussion to 
the fuse-devel list.

It seems that not all FUSE filesystems are compatible with the way 
applications work with POSIX.

IMHO one possible solution would be a "metastatfs" library that 
applications and high level filesystem abstraction layers (GVFS, KIO) 
can query the capabilities of a certain mount:

* if atomic saves work
* information about permission mapping
* other meta information (target of the mount "ftp://user@server", hints 
for desktop file-management set as mount options: use Trash, render 
Previews,...)

norbert

Alexander Larsson wrote:

On Mon, 2007-07-16 at 02:53 +0200, nf2 wrote:

  

> Alexander Larsson wrote:
>    
>> It doesn't work that way. How should gedit implement saving? If we're
>> not requiring fuse everywhere it really *must* use the gvfs API. And
>> even if we *do* require fuse, using the standard posix way of doing
>> atomic save with backup (which gedit does atm) just doesn't work well on
>> non-posix systems. We need higher level operations that does what
>> application authors want and can be implemented differently on different
>> backends. And special ioctls doesn't help with this.
>>         
> i already realized that gedit doesn't like to save files on fusesmb 
> ("directory busy"). how does this atomic save work exactly?
> (on other FUSE filesystems - sshfs, curlftfs i had no problems saving 
> files). and gedit seems to be quite picky. didn't encounter any such 
> problems with other applications yet... well ... except vi: it says 
> "Close error on swap file" when editing a text file on a curlftpfs 
> mount, but unlike gedit it didn't have problems on fusesmb... this 
> really sucks...
>
> i would like to write a little FUSE - filesystem test-suite now, to be 
> able to demonstrate such problems... perhaps you can give me some 
> hints which (sequence of) fs-operations should be checked...
>     

I don't know exactly what part fails in the particular case of gedit. I
know hpj had issues with it when the chmod() of the backed up file
failed when gedit was trying to make the permissions the same on the
backup as the original (of course, setting unix permissions on a smb
backend won't work). In general, posix is more than the set of
operations availible, it also includes the behaviour of them, and if any
such behaviour is violated by the filesystem, then apps are likely to
break in unknown ways.

For example, read "man 3p rename" for the posix spec on how the rename
syscall should work. In particular this part:

  If the link named by the  new  argument exists,  it  shall  be removed
  and old renamed to new. In this case, a link named new shall remain
  visible to other processes throughout the renaming operation and refer
  either to  the file  referred  to  by  new  or  old  before the
  operation began.

This behaviour is what is used to implement atomic saves on posix. You
just write to a temporary new file in the same directory, and then when
done you rename over the final name. Posix mandates that during the
whole thing nobody will ever see a partially written file with that
filename, only the original version or the fully written new version.
This is what is known as "atomic save", and you need it to avoid data
loss if the app crashes when the file is half-saved.

Now, this behaviour is impossible to implement on e.g. a ftp share, and
the way you implement atomic saves there is different (its generally
backend specific). This makes posix a less than ideal high-level API for
apps.