Comment 5 for bug 1846790

Description:
[This was originally reported on the Ubuntu bug tracker, see https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1846790, where it's been requested that I kick it upstream, on the grounds that the official 6.3.2 .deb is also affected. I've taken the liberty of expanding it and simplifying the test cases.]

Somehow, when LibreOffice saves a file containing '#' on a Samba share accessed via a GVFS smb:// path the filename gets truncated at the first '#', inclusive, suffix and all, before the save actually happens. As a result, the data isn't saved where the user intended, so from their perspective, it didn't save at all. Without an error message or any indication that something didn't work. What's worse, if the truncated destination file already exists, it is silently overwritten, causing actual data loss, in unrelated data.

'#' in directory names are ok. The problem does not occur with local files or on a sshfs-mount. Gedit has no problem even on smb://. It's unclear whether '#' is the only character affected.

Some kind of URL handling/escaping bug in LibreOffice's GIO support?

In any case, this cost me a day of work. (By the time I realised my changes hadn't actually been lost but landed in a new, cryptically-named file, I'd already recreated it to meet the deadline.)

Steps to Reproduce:
Save a file whose name contains a '#' character to a Samba share accessed via a GVFS smb:// path.
Ex. 1: Open a blank Writer (ODT) document, save that under the name "Test#1.odt" on a Samba share mounted via Nautilus.
Ex. 2: Open a pre-existing file "Test#2.odt", either via Nautilus or File-Open, make some changes, save it & quit.
Ex. 3: As either of the above, but with "Test #3.odt" being the intended filename. [This is the original bug/test case.]

Actual Results:
Ex. 1: LibreOffice actually saves the data in a file named "Test" [note the lack of an extension].
Ex. 2: The original file remains untouched, but a new file "Test" is created.
Ex. 3: The data goes to "Test " [note the space at the end], which displays as "TFNZPF~F" on the client. (Filenames ending in a space aren't legal under Windows, so Samba's name mangling kicks in.)

Expected Results:
The file shows up under the assigned name (in case of a new file); or the existing file now contains the changes made (in case of an existing file being modified).
Ex. 1: I'd expect to see "Test#1.odt" in the relevant directory.
Ex. 2: I'd expect "Test#2.odt" to contain my changes.
Ex. 3: As above, but for "Test #3.odt".

Reproducible: Always

User Profile Reset: No

Additional Info:
Version: 6.0.7.3
Build-ID: 1:6.0.7-0ubuntu0.18.04.10
CPU-Threads: 24; BS: Linux 5.0; UI-Render: Standard; VCL: gtk3;
Gebietsschema: de-AT (de_DE.UTF-8); Calc: group

This is the Ubuntu 18.04 (bionic) distro version of LO. I'm not sure if OpenGL is active or not, the info on where to check doesn't seem to be applicable.

Linux Mint 19.3 (Cinnamon) is also affected.