GNOME Bugzilla – Bug 748106
Add operations to support O_WRONLY and O_RDWR in fuse daemon
Last modified: 2018-09-21 17:47:49 UTC
After upgrade from 1.22 to 1.24 on Arch Linux smb:// and sftp:// both return EOPNOTSUPP if a file is attempted to be opened as writable (O_WRONLY or O_RDWR). I believe this problem is not backend-specific.
That is indeed true. GIO does not provide the correct high level operations to provide those operations. They should work if O_TRUNC is also used. This was changed in bug 632296 because the existing implementation caused data loss in several cases. I will change this into a enhancement request to provide these operations. Note that using gvfs through the fuse mechanism is a fallback implementation.
*** Bug 748675 has been marked as a duplicate of this bug. ***
*** Bug 749687 has been marked as a duplicate of this bug. ***
*** Bug 753065 has been marked as a duplicate of this bug. ***
*** Bug 777152 has been marked as a duplicate of this bug. ***
Created attachment 372004 [details] [review] fuse: Add fallback for unsupported write operations Currently, open() fails with ENOTSUP if O_WRONLY/O_RDWR is used without O_TRUNC, or O_APPEND, because GFileIOStream is not supported by GVfs and GIO API doesn't provide any other suitable function. Let's introduce fallback solution using a temporary file as follows: 1) Make a temporary copy of the original file with .fuse suffix (so the new file can be used as a backup if something goes wrong). 2) Replace original file using g_file_replace (i.e. using O_TRUNC) and copy back the data from the temporary file over the GFileOutputStream. 3) Finally, remove the temporary file and return the stream which was used to copy the data back. This approach copies the file twice, once into the temporary location and once back instead of just simple write, which is extremely inefficient (and fragile), but there are not many possibilities using the current API. It would be possible to make just one copy in theory, but I choose this solution to make it more bulletproof. Given the fact that is extremely inefficient, let's limit this only to small files (i.e. return ENOTSUP for big files). I initialy choose the limit to 128 MB, but it can be changed in the future if needed.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/249.