Forum is a better resource then the developer Issue tracker.
You might want to check the general Ideas on this thread maybe:
https://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=36661

If that does not help please open a new thread on the Forums. Thanks.
I close the Issue in order to keep track on Code oriented Issues ;) We have plenty of those.

All the Best
Peter

This really is a longstanding bug.

It will never get fixed when we simply ignore it.

(In reply to Peter from comment #1)

> I close the Issue in order to keep track on Code oriented Issues

Apache OpenOffice is the ONLY software running on my system that DOES NOT open files by association.

In fact I can open any Open Documents located on the Samba folder by association using LibreOffice, so I believe this proves it is an Apache OpenOffice issue.

I'm taking the liberty of Reopening the issue because the issue still occurs on version 4.1.7 and I believe it was a misinterpretation of my original post.

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".

(In reply to damjan from comment #4)

> 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?)

Can you provide an example of an SSH filesystem? I'm not sure what that means.

> 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.

This bug does not affect any other software (including LO). I can open any file on these shared folders with any application, except for AOO under Linux. AOO under Windows opens all files without issues
 
> 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.

Easy is better ;) Is this gvfs of any use? Maybe it can all be completely removed? 
 
> 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".

Please provide an example of SSH or SFTP. I used FTP decades ago, but we don't have any of that any longer.
I will test point 2 on Monday

Thanks!

(In reply to Pedro from comment #5)
> (In reply to damjan from comment #4)
> 
> > 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?)
> 
> Can you provide an example of an SSH filesystem? I'm not sure what that
> means.

For example if you install OpenOffice in a Linux guest VM in VirtualBox, with a NAT type network interface, your host IP address will be 10.0.2.2. And if you have a SSH server on the host, and you open a file manager in the guest, and type:
sftp://10.0.2.2/
it should open the filesystem root (/) on the host machine.

I've tested that and I can reproduce this bug with SSH too, so it's NOT Samba-specific. It is that notorious gvfsd-fuse bug I predicted earlier.

> > 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.
> 
> This bug does not affect any other software (including LO). I can open any
> file on these shared folders with any application, except for AOO under
> Linux. AOO under Windows opens all files without issues

This other Linux software probably does one of the following:
- Uses simpler POSIX file APIs which work fine on gvfs-fuse. We cannot use the simpler APIs, because we do more advanced things with files, for example we probably seek to the file start multiple times, so each filter can detect the file type.
- Uses GIO APIs directly instead of POSIX APIs ("option 2" in my previous post).

Windows doesn't use FUSE and gvfsd-smb to access SMB, it does something else, probably an in-kernel SMB/CIFS filesystem.

> > 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.
> 
> Easy is better ;) Is this gvfs of any use? Maybe it can all be completely
> removed? 

gvfs is a system component present on Linux distributions. We do not ship it and we end up using it unintentionally, because it acts as an implicit gio plugin. But we can use less of it, bypassing the problematic gvfsd-fuse component.

> > 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".

In my own tests:

1. Yes, it happens with SSH/SFTP too.
2. The URL works, because it uses GIO directly, bypassing gvfsd-fuse.

If you start AOO in a debugger, then Ctrl+C, "break open", "c", and then double-click on a file on a remote server accessed over SFTP from the file manager, you get this:

#0  __libc_open64 (file=0x7fffffffb600 "/run/user/1000/gvfs/sftp:host=10.0.2.2/tmp//helloworld.odt", oflag=2)
    at ../sysdeps/unix/sysv/linux/open64.c:30
#1  0x00007ffff7a3769a in osl_openFile () at /opt/openoffice4/program/libuno_sal.so.3
#2  0x00007fffd7c2dad3 in  () at /opt/openoffice4/program/../program/libucpfile1.so
#3  0x00007fffd7c29a72 in  () at /opt/openoffice4/program/../program/libucpfile1.so
#4  0x00007fffd7c13657 in  () at /opt/openoffice4/program/../program/libucpfile1.so
#5  0x00007fffd7c0f38b in  () at /opt/openoffice4/program/../program/libucpfile1.so
#6  0x00007fffd7c114fd in  () at /opt/openoffice4/program/../program/libucpfile1.so
#7  0x00007ffff364472d in  () at /opt/openoffice4/program/libucbhelpergcc3.so
#8  0x00007ffff3646f1a in ucbhelper::Content::openWriteableStream() () at /opt/openoffice4/program/libucbhelpergcc3.so
...

So we see the file path passed to AOO was:

/run/user/1000/gvfs/sftp:host=10.0.2.2/tmp/helloworld.odt

which is the path to the FUSE mounted gvfsd-fuse filesystem (from the output of "mount"):

gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

Also in that stack trace, we see it decided to use libucpfile1.so, treating it as an ordinary POSIX file. We might have better luck if we translate that path to a GIO path and force it to use libucpgio1.so.

I'll need a debug build of AOO to debug further.

(In reply to damjan from comment #7)

> I'll need a debug build of AOO to debug further.

I can't build any branch other than 41X under Ubuntu 18.04
If you can build the trunk debug build please let me know.
I'm available to test but unfortunately I can't build any trunk binaries...

(In reply to damjan from comment #4)

> 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".

Confirmed that the GIO URL works. As I mentioned in the original post, any other way of opening the file, from recent documents or by typing on the Open dialog (native or internal) works.

The problem is opening from file association

If/when you manage to compile a debug build please send me a link