[upstream] Saving files with a '#' in the name silently(!) fails on GVFS smb:// paths (Samba share)

[Christian Pernegger]

[Reported via ubuntu-bug, I'm assuming it has gathered all relevant system info. More, especially on the Samba server, if required, is available on request.]

What I'm trying to do:
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.

What I'm expecting to happen:
The file shows up under the assigned name on both the client and the Samba server (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.

What happens instead:
Ex. 1: LibreOffice actually saves the data in a file named "TFNZPF~F" as seen from the client, "Test " [note the space at the end] on the server.
Ex. 2: The original file remains untouched, but a new file "TFNZPF~F" (client), or "Test " (server) is created with the saved data.
Effectively, the save operation does not succeed -- without any error message.

Analysis:
This is based on experiments with more complex filenames. Somehow, when LibreOffice saves a file in this constellation, the filename gets truncated at the first '#', inclusive, first, suffix and all. (This in turn leaves a filename ending in a space, which isn't legal under Windows, so Samba's name mangling kicks in.)

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

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: libreoffice-gnome 1:6.0.7-0ubuntu0.18.04.10
ProcVersionSignature: Ubuntu 5.0.0-29.31~18.04.1-generic 5.0.21
Uname: Linux 5.0.0-29-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Fri Oct 4 17:12:21 2019
InstallationDate: Installed on 2019-09-23 (10 days ago)
InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805)
SourcePackage: libreoffice
UpgradeStatus: No upgrade log present (probably fresh install)

[Marcus Tomlinson (marcustomlinson)]

Hi Christian, evidently this is not an Ubuntu-specific issue. I've managed to reproduce this on Debian Stretch with TDF's own 6.3.2 deb (https://www.libreoffice.org/download/download/?type=deb-x86_64).

Could I please ask you to file an upstream bug for this at https://bugs.documentfoundation.org/enter_bug.cgi?product=LibreOffice&format=guided and share the link to that bug here?

Thank you!

[Christian Pernegger (fallenguru)]

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.

[Christian Pernegger (fallenguru)]

Sure, here you go: https://bugs.documentfoundation.org/show_bug.cgi?id=128196.
I've added some more info there as well, most importantly that LO will silently overwrite anything that already exists with the truncated name, e.g. trying to save "clobber#1.odt" will overwrite an existing "clobber".

[Marcus Tomlinson (marcustomlinson)]

Excellent, thanks Christian.

[Christian Pernegger (fallenguru)]

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.

[Xiscofauli (xiscofauli)]

Hello <email address hidden>,
Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.

[Qa-admin-q (qa-admin-q)]

Dear pernegger,

This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.

For more information about our NEEDINFO policy please read the
wiki located here:
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO

If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-NeedInfo-Ping

[Christian Pernegger (fallenguru)]

(In reply to Xisco Faulí from comment #2)
> Could you please try to reproduce it with the latest version of LibreOffice [Fresh]

I'm aware that this was a rhetorical question, but, no, I'm afraid I could not, at least not easily.

Firstly, I try to stick to software from official distribution repos, especially on production systems (and I have no sandbox at the moment); and I can't risk LO breaking because the distro version interferes with the upstream one. (There isn't an official portable version, is there?)
Secondly, this is a bug in the stable series and I think it should be fixed there.

For the record, both the version currently in Ubuntu 18.04 [6.0.7.3] and 20.04 [6.4.6.2] are still affected.

This bug is trivial to reproduce. Back when I reported this, someone else had no problem reproducing on Debian using [LO's] 6.3.2, see https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1846790/comments/2.

* Are you saying that you tried to reproduce it, but cannot?
* Can you point to a change in the code that should have fixed it?

If so, I'll find the time to spin up a VN or something, otherwise I'd respectfully like to point out that it'd be a lot quicker for someone who's already using the bleeding-edge version to re-test this.

[Michael-warner-ut+libreoffice (michael-warner-ut+libreoffice)]

(In reply to pernegger from comment #4)
> (There isn't an official portable version, is there?)

Actually, yes, there is:
https://www.libreoffice.org/download/portable-versions/

[Michael-warner-ut+libreoffice (michael-warner-ut+libreoffice)]

(In reply to pernegger from comment #4)
> (There isn't an official portable version, is there?)

Sorry, I just noticed you are using Linux. So, perhaps this is the one you want:
https://www.libreoffice.org/download/appimage/

[Christian Pernegger (fallenguru)]

(In reply to Michael Warner from comment #6)
> https://www.libreoffice.org/download/appimage/

Ah. How'd I miss that? For some reason I only found the PortableApps.com thing, which is Windows-only.

Alrighty ...
Appimage from the above URL, Basic-Fresh flavour, which gives the following version info

Version: 7.1.3.2 / LibreOffice Community
Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1
CPU threads: 24; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (en_UK); UI: en-US
Calc: threaded

is STILL AFFECTED by this bug, the behaviour is unchanged.

[julien2412 (serval2412-6)]

On pc Debian x86-64 with master sources updated today, I could reproduce this.

I installed Samba (for the first time, I thought it would have been more complicated) following https://ubuntu.com/tutorials/install-and-configure-samba#1-overview.
Then:
- "File/Save Remote..."
- Manage service, Windows share and configured it
- saved a brand new file named test#1.odt
=> it saved a file just named "test"

[julien2412 (serval2412-6)]

I gave a try with https://gerrit.libreoffice.org/c/core/+/136084

[Libreoffice-commits (libreoffice-commits)]

Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2a38c834c8b7712421f1125aa0e382de70767b55

tdf#128196: filenames containing # get truncated when saving to GVFS

It will be available in 7.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

[julien2412 (serval2412-6)]

patch for 7.4 waiting for review here:
https://gerrit.libreoffice.org/c/core/+/136121

patch for 7.3 waiting for review here:
https://gerrit.libreoffice.org/c/core/+/136122

[Libreoffice-commits (libreoffice-commits)]

Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-7-4":

https://git.libreoffice.org/core/commit/7aaa23573d5a4998fea6f42f0a8b45b03de7509a

tdf#128196: filenames containing # get truncated when saving to GVFS

It will be available in 7.4.0.0.beta2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

[Libreoffice-commits (libreoffice-commits)]

Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/b95071969d95cbf3d56b53286ccefd4c43033fc1

tdf#128196: filenames containing # get truncated when saving to GVFS

It will be available in 7.3.5.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

[Christian Pernegger (fallenguru)]

For the record, I can confirm that the version of LO that ships with 22.04 is no longer affected.