From: Alexander Larsson <alexl@re...> - 2007-07-25 11:40:15
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,