From: Alexander L. <al...@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, unfortunately. |