Bug 128196 - filenames containing '#' get truncated when saving to GVFS smb:// paths (Samba share), effectively causing silent data loss
Summary: filenames containing '#' get truncated when saving to GVFS smb:// paths (Samb...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.7.3 release
Hardware: All Linux (All)
: medium normal
Assignee: Julien Nabet
URL:
Whiteboard: target:7.5.0 target:7.4.0.0.beta2 tar...
Keywords:
Depends on:
Blocks: Network
  Show dependency treegraph
 
Reported: 2019-10-17 10:00 UTC by pernegger
Modified: 2022-06-20 08:06 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description pernegger 2019-10-17 10:00:23 UTC
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.
Comment 1 pernegger 2019-10-17 10:58:50 UTC
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.
Comment 2 Xisco Faulí 2020-11-18 15:22:37 UTC
Hello pernegger@gmail.com,
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.
Comment 3 QA Administrators 2021-05-19 04:39:26 UTC Comment hidden (obsolete)
Comment 4 pernegger 2021-05-22 14:13:18 UTC
(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.
Comment 5 Michael Warner 2021-05-23 03:15:35 UTC Comment hidden (obsolete)
Comment 6 Michael Warner 2021-05-23 03:19:55 UTC
(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/
Comment 7 pernegger 2021-05-23 19:31:44 UTC
(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.
Comment 8 Julien Nabet 2022-06-18 10:13:44 UTC
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"
Comment 9 Julien Nabet 2022-06-18 13:17:49 UTC
I gave a try with https://gerrit.libreoffice.org/c/core/+/136084
Comment 10 Commit Notification 2022-06-19 18:43:43 UTC
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.
Comment 11 Julien Nabet 2022-06-19 18:46:02 UTC
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
Comment 12 Commit Notification 2022-06-20 07:15:51 UTC
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.
Comment 13 Commit Notification 2022-06-20 08:06:12 UTC
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.