Remount operation
Submitted by Tomas Bzatek
Link to original bug (#590007)
Description
The GIO subsystem was designed to allow authentication only during mount operation (i.e. only one place with clear result mounted/not-mounted). Once a resource is mounted, it's not possible to re-authenticate or remount (modify) the mount in any other way.
Now imagine you have an ACL-enabled resource where every folder can have different permissions and/or is possible (from backend side) to do re-authenticate as a different user.
One common use case is WebDAV, based on HTTP authentication. Auth request can come on first write attempt, thus undetectable during mount (first read operation). This breaks gnome-user-share usability when password protection is only set for writing.
So we were thinking about several ways to work around this issue with as little API changes as possible and came up with this solution:
- introduce new G_IO_ERROR_NEEDS_REMOUNT
- introduce new g_file_remount () with arguments similar to g_file_mount_mountable () or g_file_mount_enclosing_volume (), i.e. passing GMountOperation instance to handle new auth request.
If unhandled, G_IO_ERROR_NEEDS_REMOUNT would just mean G_IO_ERROR_PERMISSION_DENIED, only giving a hint that remount/re-authentication is possible. We can set some nice verbose error message too. Applications should handle this error similarly to G_IO_ERROR_NOT_MOUNTED, only calling g_file_remount (). Looking at Nautilus code, it should not be difficult to support this feature.