Saving image fails with GVFS SFTP backend
When trying to save a file on a GVFS backend that doesn't provide a value for whether a file is writable or not, Eye of GNOME cannot save the image, telling:
Could not save image “xyz.jpg”.
You do not have the permissions necessary to save the file.
For me, this happens with a remote SFTP filesystem:
$ ssh remote ls -al /path/to/image.jpg
-rw-rw-r-- 1 remoteuser remotegroup 733385 Jan 1 2000 /path/to/image.jpg
$ ls -al /run/user/1000/gvfs/sftp\:host=remote/path/to/image.jpg
-rw-rw-r-- 1 localuser localgroup 733385 Jan 1 2000 /run/user/1000/gvfs/sftp\:host=remote/path/to/image.jpg
$ gio info sftp://remote/path/to/image.jpg
display_name: image.jpg
edit_name: image.jpg
name: image.jpg
type: regular
size: 733385
uri: sftp://remote/path/to/image.jpg
local path: /run/user/1000/gvfs/sftp\:host=remote/path/to/image.jpg
unix mount: gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000
attributes:
standard::type: 1
standard::name: image.jpg
standard::display-name: image.jpg
standard::edit-name: image.jpg
standard::icon: image-jpeg, image-x-generic, image-jpeg-symbolic, image-x-generic-symbolic
standard::content-type: image/jpeg
standard::fast-content-type: image/jpeg
standard::size: 733385
standard::symbolic-icon: image-jpeg-symbolic, image-x-generic-symbolic, image-jpeg, image-x-generic
etag::value: (redacted)
id::filesystem: sftp:host=remote
access::can-read: TRUE
access::can-trash: FALSE
time::modified: (redacted)
time::access: (redacted)
unix::mode: 33204
unix::uid: 1000
unix::gid: 2000
thumbnail::path: (redacted)
As you can see, access::can-write
is missing. As GVFS's backends page shows below Metadata operations, SFTP mentions try (though I'm not fully sure what that means, it looks like it means the metadata operation may succeed or it may not).
The error happens in eog_image_save_by_info
, ultimately g_file_info_get_attribute_boolean
is called, which returns FALSE
when no value is present, which is the case here.
Looking around, I found Thunar to have removed the check. I'm not sure what would be best here, but perhaps the least we can do is allow the operation when the metadata attribute access:can-write
is missing. Perhaps g_file_info_get_attribute_type
might be called first.