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