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 -- 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: Incomplete 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 : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
