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