(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. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/1846790 Title: [upstream] Saving files with a '#' in the name silently(!) fails on GVFS smb:// paths (Samba share) Status in LibreOffice: New Status in libreoffice package in Ubuntu: Confirmed Bug description: [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) To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/1846790/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
