Miklos Szeredi wrote:
>>> 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,
> 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.
Hmm... On the one hand FUSE seems problematic because of those POSIX
issues. You'll probably need well designed guidelines for application
and filesystem developers (FUSE wiki?).
On the other hand all attempts to bypass the operating system with VFS
libraries - trying to hide and neglect it in the cellar like an ugly
beast, have failed because being too over-sophisticated and incoherent
(and IMHO all linux desktops still have serious interfacing problems
with their operationg system).
I still like FUSE as the "Keep It Simple, Stupid" approach - as fixing
things at the lowest possible layer usually works best - and i believe
GVFS should be a convenience and portability layer on top of it (rather
than having a FUSE bridge into GVFS which creates two classes of
applications and lots of usability and consistency problems).