From: Alexander Larsson <alexl@re...> - 2007-07-25 11:38:56
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
> > 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...
Get latest updates about Open Source Projects, Conferences and News.