https://bz.apache.org/ooo/show_bug.cgi?id=128049
--- Comment #7 from [email protected] --- 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. -- You are receiving this mail because: You are the assignee for the issue.
