After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 768281 - Fuse prefix is not recognized for symlinked files during GFile object creation
Fuse prefix is not recognized for symlinked files during GFile object creation
Status: RESOLVED OBSOLETE
Product: gvfs
Classification: Core
Component: fuse
git master
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
: 774303 774371 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2016-07-01 13:56 UTC by Dariusz Gadomski
Modified: 2018-09-21 18:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
full vfs.debug (39.55 KB, text/plain)
2016-07-01 13:56 UTC, Dariusz Gadomski
Details

Description Dariusz Gadomski 2016-07-01 13:56:30 UTC
Created attachment 330723 [details]
full vfs.debug

Platform:
Ubuntu from 14.10+ (including the latest 16.04)

Steps to reproduce:
1. Setup a gvfs mount (I used smb and sftp shares configured via nautilus).
2. Create a symlink to the fuse-mounted location e.g.
cd ~/Desktop; ln -sf /run/user/1000/gvfs/smb-share:server=10.0.20.6,share=share1/symlinktest
3. Navigate with nautilus to the symlinked location, open a file available there with e.g. gedit or libreofficeand try to save it.

Expected result:
File is saved.

Actual result:
An enigmatic error message is displayed
(Cannot handle "file:" locations in write mode - for gedit, or "General input/output error while accessing <path>" for libreoffice).

The problems started with commit 548ba46c2ba51c4ec5b0dd8442b476f3a2a7000b fuse: Don't g_file_append_to unless O_APPEND is given. Reverting it makes the issue disappear.

I have rebuild gvfs enabling debugging (#define DEBUG_ENABLED 1) and here is what I got in ~/vfs.debug:
# accessing via symlink
vfs_open: /smb-share:server=10.0.20.6,share=share1/grouptest/symlinktest/test
open_common: flags=500002
vfs_open: -> Operation not supported
# accessing via /run/user/(...)
vfs_open: /smb-share:server=10.0.20.6,share=share1/grouptest/symlinktest/test
open_common: flags=1100000
setup_input_stream: have stream
setup_input_stream: doing read
vfs_open: -> Success

For reasons beyond my understanding the flags are different while accessing the file via the default gvfs-mountpoint causing the execusion to skip the modified section of client/gvfsdfusedaemon.c (returning -ENOTSUP).

I am attaching the full vfs.debug created.
Comment 1 Ondrej Holy 2016-08-11 13:57:49 UTC
Thanks for your bug report.

I see more problems here...

Gedit is based on GIO. So GIO is used directly instead of FUSE even if you open Gedit with a path like /run/user/(...). Unfortunately, FUSE is used if you open the file in Gedit over the symlink instead of GIO, because the prefix doesn't match the FUSE mount point. I think that this can be fixable. Not sure about LibreOffice on Ubuntu, but it should also use GIO, so there is the same problem.

Another problem is that you can't open files for writing over FUSE without O_TRUNC, or O_APPEND. It used to work before the commit you mentioned, but it let to data loss in some cases which is not acceptable. The problem is that GIO API isn't fully compatible with POSIX API, see Bug 632296. I can imagine a fallback solution for this, but I am afraid it might be pretty fragile and inefficient.

So I think we can still fix this for applications which are based on GIO, but I am not really sure about rest of the applications.
Comment 2 Ondrej Holy 2016-08-23 13:48:06 UTC
(In reply to Ondrej Holy from comment #1)
> Gedit is based on GIO. So GIO is used directly instead of FUSE even if you
> open Gedit with a path like /run/user/(...). Unfortunately, FUSE is used if
> you open the file in Gedit over the symlink instead of GIO, because the
> prefix doesn't match the FUSE mount point. I think that this can be fixable.

There is a problem that the prefix is compared during GFile object creation and any I/O should not be done at that point, hmm...
Comment 3 marc 2016-08-25 20:54:52 UTC
it seems to be also connected to message "General input/output error while accessing" xxxxx/xxxx/xxxx/ when opening such files with LibreOffice 5.2.0.4 (Mint 18).
Comment 4 Dariusz Gadomski 2016-08-26 13:31:23 UTC
(In reply to Ondrej Holy from comment #2)
> There is a problem that the prefix is compared during GFile object creation
> and any I/O should not be done at that point, hmm...

Does it mean that it may be a result of an error?
Comment 5 Dariusz Gadomski 2016-08-26 13:32:08 UTC
(In reply to Dariusz Gadomski from comment #4)
> Does it mean that it may be a result of an error?
And by 'an error' I mean 'a bug'.
Comment 6 Ondrej Holy 2016-11-14 08:17:24 UTC
*** Bug 774371 has been marked as a duplicate of this bug. ***
Comment 7 Brian 2016-11-14 09:23:21 UTC
This is preventing me from being able to use meld 3.15.2+, so for now I'm having to use meld 3.15.1 which still uses the plain Python file I/O API. Is there any progress on solving this in some way?
Comment 8 Ondrej Holy 2016-11-14 10:01:50 UTC
I see, sorry, did not have time to deal with it, but have it on my TODO. Patches are welcome if somebody wants to help...
Comment 9 Sébastien Wilmet 2016-12-07 12:07:27 UTC
*** Bug 774303 has been marked as a duplicate of this bug. ***
Comment 10 Ondrej Holy 2017-01-17 09:09:35 UTC
Let's limit this bug report to the symlink issue and use Bug 777152 for write operations without O_TRUNC, nor O_APPEND...
Comment 11 GNOME Infrastructure Team 2018-09-21 18:00:04 UTC
-- 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/283.