Description: Open existing document where the option to "Hide Suffix" is enabled in macOS Finder (file manager) If the file is changed and saved LO adds the file suffix and the option to "Hide Suffix" is not enabled any longer. tested with odt and ods files. 100% reproducible Steps to Reproduce: see description Actual Results: File suffix is added on save Expected Results: file suffix should stay hidden if setting for that is enabled Reproducible: Always User Profile Reset: No Additional Info:
Hi Steve, I don't seem to be able to test this. Even if I turn off this option (Display Extensions) in the Finder preferences, restart the machine and log back in, I still see file extensions in the Finder window. Is there something else I should be doing ?
Are you in IRC @alex? This should be fairly simply to reproduce. Using macOS 10.13.6 here.
Ok, I've got it now. I was trying the global hide extension approach instead of individual hiding via the Cmd-I properties dialog. Confirming with LO6103
adding regression keyword since this is a new bug and adjusting earliest affected version to 6.1.0.3
Steps to reproduce: 1) Select an ODF file in the Finder 2) Cmd-I or context menu on selected file to open the Properties dialog, tick the box "hide extension" 3) Close dialog, then open file in LibreOffice. 4) Make a change, save, then close LibreOffice. 5) In Finder, notice how the file extension is displayed once again.
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=2157a3536f97ff5ae7c82611a801fef7e3708983 author Miklos Vajna <vmiklos@collabora.co.uk> 2018-01-08 16:49:25 +0100 committer Miklos Vajna <vmiklos@collabora.co.uk> 2018-01-09 09:09:27 +0100 commit 2157a3536f97ff5ae7c82611a801fef7e3708983 (patch) tree 1f7e5267a0d97d55800f20f73fa3f022023abc28 parent 5259ab8104cfba60c40748ed0cd59d93df038c5b (diff) sfx2 store: try rename before copying Rename is cheaper then copying the content over manually, so try that first. Bisected with: bibisect-mac64-6.1 Adding Cc: to Miklos Vajna
The identified commit hasn't been backported to LO 6.0, so either the bibisect result or the earliest affected version (6.0.6.1) is wrong.
The later; the bibisect result is correct.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7823684cb6fbe752dc64300799c5d102f61e0b70 tdf#119316 sfx2 store: no move on macOS It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
My bad, sorry. I tested various versions and must have confused them. Setting earliest version back to 6.1.0.3.
macOS nightly builds are dead due to a hardware issue atm.
Verified in Version: 6.2.0.0.alpha0+ Build ID: 3d39dad6d93c979ac64244ecb9acfbd8a5fbd6c6 CPU threads: 8; OS: Mac OS X 10.13.6; UI render: default; Locale: en-US (en_ES.UTF-8); Calc: threaded @Miklos, Thanks for fixing this!!
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f06aea9b31707ec49355e41b0e682d4a15431e44&h=libreoffice-6-1 tdf#119316 sfx2 store: no move on macOS It will be available in 6.1.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.