[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.]
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.)
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".
User Profile Reset: No
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.
https://bugs.documentfoundation.org/show_bug.cgi?id=95336 (why does one always find these *after* typing up a report?) is similar, but
- I get no error message and it definitely chops off the extension as well.
- I get it even with no file chooser dialogues involved, e.g. opening via Nautilus, then just pressing CTRL+S.
- I never had this problem with the Windows version. My naming conventions and workflow haven't changed for >5 years, it's still the same files on the same shares of the same Samba server, the only thing that's changed is that I've switched my desktop from Windows 7 to Ubuntu 18.04 recently.
- Local files are fine for me.
I'd wager the root cause hasn't been addressed and just expresses a bit differently by now.