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.
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.
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.
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
(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.
(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/
(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/
(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.
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"
I gave a try with https://gerrit.libreoffice.org/c/core/+/136084
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.
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
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.
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.