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://userserver", 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.



------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
fuse-devel mailing list
fuse-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel

> > 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.

One way to deal with this sort of problem is to add
optional
workarounds to the filesystems themselves.  E.g. the
"quiet" option
the Linux fat filesystem forces chmod/chown to return
success, even
though they fail.

> 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,

Actually FTP defines a rename procedure, that can be POSIX
compatible
(it doesn't mandate this, but on POSIX systems it's the
simplest thing
to do).

> 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.

Even if it's not always possible to provide an atomic
rename, it's
possible to emulate the POSIX requirements, e.g. by first
removing the
target and then renaming, if rename doesn't support atomic
overwrite
(as is the case with SFTP used by sshfs).

Doing these in the filesystem has the advantage of not
needlessly
complicating all the apps.

The disadvantage, is that some app may be relying on the
exact POSIX
semantics (e.g. for locking), and then things could break. 
But I
think this is not an issue most of the time.

Miklos

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
fuse-devel mailing list
fuse-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel

> > 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.
> 
> One way to deal with this sort of problem is to add
optional
> workarounds to the filesystems themselves.  E.g. the
"quiet" option
> the Linux fat filesystem forces chmod/chown to return
success, even
> though they fail.

Actually the _best_ solution in the chmod/chown case is if
the app
actually examines the error value.  If it's ENOSYS or
EOPNOTSUPP, then
presumably the operation failed, because it does not make
sense on
that particular filesystem.  So if it is trying to copy the
file
attributes, it can safely ignore such an error.

Miklos

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
fuse-devel mailing list
fuse-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel

On Wed, 2007-07-25 at 12:45 +0200, Miklos Szeredi wrote:
> > > Alexander Larsson wrote:
> > 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.
> 
> One way to deal with this sort of problem is to add
optional
> workarounds to the filesystems themselves.  E.g. the
"quiet" option
> the Linux fat filesystem forces chmod/chown to return
success, even
> though they fail.

Thats pretty hacky though. And it makes it impossible to do
the right
thing for apps that are able to handle ENOSYS (or
whatever).

> Actually FTP defines a rename procedure, that can be
POSIX compatible
> (it doesn't mandate this, but on POSIX systems it's the
simplest thing
> to do).

Sure, its possible in some cases to handle it. Its just that
the app
can't rely on this behaviour, as guaranteed by posix. So,
there are new
failure modes.

> > 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.
> 
> Even if it's not always possible to provide an atomic
rename, it's
> possible to emulate the POSIX requirements, e.g. by
first removing the
> target and then renaming, if rename doesn't support
atomic overwrite
> (as is the case with SFTP used by sshfs).

In some cases this is quite problematic though. For
instance, if your
backing filesystem is a subversion webdav share, then you
get all these
operations recorded in the version history. Its much nicer
to have
highlevel operations for apps to use, and implement them in
the best way
possible for the specific backend. 

I realize this is not posible with fuse of course, which is
why GVFS
doesn't use fuse as its main API.

> Doing these in the filesystem has the advantage of not
needlessly
> complicating all the apps.

On the contrary, it does. It requires both the filesystem to
do weird
stuff to handle posix, and it requires app authors to use
the limited
operations of posix to implement what they need instead of
using higher
level abstractions for it. 

> The disadvantage, is that some app may be relying on
the exact POSIX
> semantics (e.g. for locking), and then things could
break.  But I
> think this is not an issue most of the time.

I think in that this will bite us in a lot more places than
we expect,
due to apps depending on specific behaviours and not
handling "weird" or
non-posix errors. Of course, I realize that there is nothing
FUSE can do
about this, and for posix-only apps this is the price we
have to pay...


------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
fuse-devel mailing list
fuse-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel

On Wed, 2007-07-25 at 12:59 +0200, Miklos Szeredi wrote:
> > > 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.
> > 
> > One way to deal with this sort of problem is to
add optional
> > workarounds to the filesystems themselves.  E.g.
the "quiet" option
> > the Linux fat filesystem forces chmod/chown to
return success, even
> > though they fail.
> 
> Actually the _best_ solution in the chmod/chown case is
if the app
> actually examines the error value.  If it's ENOSYS or
EOPNOTSUPP, then
> presumably the operation failed, because it does not
make sense on
> that particular filesystem.  So if it is trying to copy
the file
> attributes, it can safely ignore such an error.

I agree. However, the amount of applications not currently
handling this
correctly is likely to mean that is an unrealistic
solution,
unfortunately.


------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
fuse-devel mailing list
fuse-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel

> > > 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.
> > 
> > Even if it's not always possible to provide an
atomic rename, it's
> > possible to emulate the POSIX requirements, e.g.
by first removing the
> > target and then renaming, if rename doesn't
support atomic overwrite
> > (as is the case with SFTP used by sshfs).
> 
> In some cases this is quite problematic though. For
instance, if your
> backing filesystem is a subversion webdav share, then
you get all these
> operations recorded in the version history. Its much
nicer to have
> highlevel operations for apps to use, and implement
them in the best way
> possible for the specific backend. 
> 
> I realize this is not posible with fuse of course,
which is why GVFS
> doesn't use fuse as its main API.

OK, there's nothing wrong with that.  The only pitfall I see
is making
an interface too generic.  But if you have primitives like
"save file
with backup" and that sort of thing, it sounds sane.

The UNIX fs API is actually a very good abstraction and so
you should
be careful about trying to make something much better ;)

> > The disadvantage, is that some app may be relying
on the exact POSIX
> > semantics (e.g. for locking), and then things
could break.  But I
> > think this is not an issue most of the time.
> 
> I think in that this will bite us in a lot more places
than we expect,
> due to apps depending on specific behaviours and not
handling "weird" or
> non-posix errors. Of course, I realize that there is
nothing FUSE can do
> about this, and for posix-only apps this is the price
we have to pay...

Experience shows, that this works rather well.  I think
ntfs-3g does
the "quiet" thing by default and it doesn't seem
to cause problems,
despite being widely used.

Miklos

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
fuse-devel mailing list
fuse-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel

> > Actually the _best_ solution in the chmod/chown
case is if the app
> > actually examines the error value.  If it's ENOSYS
or EOPNOTSUPP, then
> > presumably the operation failed, because it does
not make sense on
> > that particular filesystem.  So if it is trying to
copy the file
> > attributes, it can safely ignore such an error.
> 
> I agree. However, the amount of applications not
currently handling this
> correctly is likely to mean that is an unrealistic
solution,
> unfortunately.

I think the best solution is to make it optional.  If it
breaks your
app, turn on the workaround _and_ report it to the app's
developers.

If for example this is breaking gedit, that should be fixed.
 Fending
off such bug reports refering to POSIX doesn't work.  Some
filesystem
just can't be made compliant.

But I don't think that anything much more complex than
checking for an
error value should be needed to work around non-posixy
filesystems.

Miklos

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
fuse-devel mailing list
fuse-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel

On Wed, 2007-07-25 at 14:00 +0200, Miklos Szeredi wrote:
> > > > 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.
> > > 
> > > Even if it's not always possible to provide
an atomic rename, it's
> > > possible to emulate the POSIX requirements,
e.g. by first removing the
> > > target and then renaming, if rename doesn't
support atomic overwrite
> > > (as is the case with SFTP used by sshfs).
> > 
> > In some cases this is quite problematic though.
For instance, if your
> > backing filesystem is a subversion webdav share,
then you get all these
> > operations recorded in the version history. Its
much nicer to have
> > highlevel operations for apps to use, and
implement them in the best way
> > possible for the specific backend. 
> > 
> > I realize this is not posible with fuse of course,
which is why GVFS
> > doesn't use fuse as its main API.
> 
> OK, there's nothing wrong with that.  The only pitfall
I see is making
> an interface too generic.  But if you have primitives
like "save file
> with backup" and that sort of thing, it sounds
sane.

Yes, its tricky to draw the line at the right place when
abstracting
posix. I'm staying pretty close, but making it more
abstract/generic
where I think it matters.

This is what I have for save:

GFileOutputStream *g_file_replace (GFile         *file,
				   const char    *etag,
				   gboolean       make_backup,
				   GCancellable  *cancellable,
				   GError       **error);




------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
fuse-devel mailing list
fuse-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel