https://bz.apache.org/ooo/show_bug.cgi?id=128049
dam...@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dam...@apache.org
--- Comment #4 from dam...@apache.org ---
The path:
/run/user/1000/gvfs/smb-share:server=cripsul,share=publica/folder/file.xls
is a virtual filesystem, created by the GVFS daemon
(https://wiki.gnome.org/Projects/gvfs) mentioned in "There is also FUSE support
that provides limited access to the GVfs filesystems for applications not using
GIO." (https://wiki.gnome.org/Projects/gvfs).
The architecture of this FUSE filesystem is something like this:
Apps (eg. OpenOffice)
|
v
libc gvfsd-fuse
| ^ |
| | |(gio API)
| | v
| | gvfsd-smb
| | |
| | v
| | libsmbclient
v | |
----------|-----|-----------
kernel | |
| | v network
v | network I/O ----------------> SMB server
VFS |
| |
v |
+-------------+
| FUSE |
+-------------+
And GVFS provides many other backends, eg. FTP, SSH/SFTP, NFS, archive, WebDAV,
etc. Those would be implemented similarly, with gvfsd-smb replaced by the
relevant backend service, which implements that virtual filesystem however it
likes.
Now if I am correct, ALL these services would suffer from this bug, ie. opening
an SSH filesystem in your file browser and trying to double-click on an .xls
file there, would also get "General input/output error while accessing
<filename>" in OpenOffice. (Can someone confirm?)
And if that happens, I know exactly why it happens.
Firstly FUSE has practically become a Linux-only project, with APIs so specific
to Linux that they cannot be implemented anywhere else. See the discussion on
FreeBSD's bug tracker at
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236340 where they said it
cannot be supported, "just like OSX, NetBSD, OpenBSD, or Illumos". With users
and developers of those others excluded, of course it gets less tested and has
more bugs, with less incentive to fix it. Software depending on FUSE's
Linux-only features, also gets used and tested and fixed less by those on other
OSes, and thus suffers from this Linux-only fundamentalism.
Now the actual bug is in gvfsd-fuse, which has to translate POSIX system calls
coming from applications (like OpenOffice), into GIO API calls to GVFS backends
(like gvfsd-smb). Older versions of GIO only supported very general high-level
operations that couldn't cater to all POSIX APIs, particularly all the open()
flags. New versions of GIO do support a broader open() API that would be
better. Unfortunately, to use the new GIO API, 9 new methods need to be
implemented in each of the many GVFS backends. Each of these methods is
extremely complex to implement, as these backend run in separate processes,
using an application-private DBus connection to make remote procedure calls to
them.
This is the infamous gvfs bug: https://gitlab.gnome.org/GNOME/gvfs/-/issues/249
which breaks many other applications too (LibreOffice included, at least back
in 2019), and has not been fixed in 9 years, and has little hope of being fixed
upstream.
Now I see 2 ways to fix this:
1. We submit patches to GVFSD to get gvfsd-fuse fully supporting the POSIX file
APIs like it should, which would also allow gvfsd-fuse to work on other
operating systems. That's a lot of work though.
2. We change OpenOffice to detect that the file is on a gvfsd-fuse filesystem,
and attempt to use GIO API to access it directly instead, bypassing gvfsd-fuse
to do this:
Apps (eg. OpenOffice)
|
| (gio API)
v
gio
\
\
+---> gvfsd-smb
|
v
libsmbclient
|
----------------|-----------
(kernel) |
v network
network I/O ----------------> SMB server
This should be pretty easy, as we already have a GIO content provider that
could be used (in main/ucb/source/ucp/gio). It's probably also somewhat lighter
and faster.
But before we begin any development, can someone please test:
1. Does this bug happen with other filesystems such as SSH/SFTP?
2. What happens if you type the GIO URL to the file in the file open dialog? It
probably looks something like "smb://cripsul/republica/folder/file.xls".
--
You are receiving this mail because:
You are the assignee for the issue.
