Description: Writing a long text separated in various chapters, I save all chapters in one directory as e.g. "1-introduction.odt", "2-continued-text.odt" and so on. Additionally, I save copies with a timestamp in the their name in a subdirectory, e.g. "20180623-1-introduction.odt". If then working on with the timestamped version, when trying to finally again save it as "1-introduction.odt" and later opening this, all changes made in the timestamped version are lost in the not-timestamped version, while they are saved only in the timestamped version in the subdirectory. Steps to Reproduce: 1. Write a text an save it as "name.odt" in a directory. 2. Create a subdirectory, e.g. "backup", and save a copy of the document from 1. in there, named "yyyymmdd-name.odt". 3. Change the document "yyyymmdd-name.odt" from the subdirectory, choose "save as ..." and save it as "name.odt" in the higher directory, result: Changes lost in "name.odt". Actual Results: Changes got lost when repeatedly changing between two document versions by using the "save as ..." dialogue. Expected Results: original document ought to show the changes made in the backup-document after saving the latter by "save as ..." under the original name again. Reproducible: Always User Profile Reset: Yes Additional Info:
Can't reproduce it with Version: 6.1.0.0.beta2 (x64) Build ID: 0f4d2060bc90b4008fbc8e6d9a49ec7eeea60b78 CPU threads: 4; OS: Windows 10.0; UI render: GL; Locale: en-US (de_DE); Calc: CL
I didn't try try it with Windows, but suppose it is a Mac-only bug. It happens when having worked with the second version of a file, saved in a subdirectory, and then trying to save it, too, in the higher directory: When the Finder window appears to specify the place of saving, you can see the last part of the path in that Finder window. If you then click on the desired original file name in the higher directory, its name appears as desired in the field for the file name to save, but the focus in the Finder window seems not to change correctly, though the last part of the path (the subdirectory name, where the backup version was saved) turns grey and a dialogue correctly appears to ask if you want to replace the version in the higher directory. Very nasty bug, which I only discovered after having erased some fattened parts of a headline which though remained after trying to overwrite the original version.
I can not reproduce in: Version: 6.0.5.1 Build ID: 0588a1cb9a40c4a6a029e1d442a2b9767d612751 CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: es-AR (es_AR.UTF-8); Calc: group
No repro for me with Version: 6.0.5.2 Build ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16 Threads CPU : 4; OS : Mac OS X 10.13.5; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group 1) Open a new Writer file, type in some text, save the file as name.odt 2) Now use "Save as" to save the original file with another file name. 3) In the Finder dialog, choose "New Folder", give the subfolder a name, and then enter a new filename, e.g.20180709-name.odt. 4) LO switches to the newly named file on validation of the "Save as" operation. 5) Now make some changes to the text in the newly created file. 6) Click on "Save as" again, and navigate up one level to choose the initial Writer file from the Finder dialog. 7) You are asked if you wish to overwrite the file. Click on Yes (Replace). 8) The new data gets written to the old file name. @a.joensson : if you are doing something different to what I have described above, then you need to be more precise with your detailed description of the steps to reproduce.
(In reply to Alex Thurgood from comment #4) > No repro for me with > > 6) Click on "Save as" again, and navigate up one level to choose the initial > Writer file from the Finder dialog. Here, it is crucial for reproduction how you behave under 6/ when selecting the original file to overwrite: I do so in a finder window where I see several columnsof the file system I am moving in, column number depends on how wide the window is. To reproduce the bug, do *not* first click on the higher level directory‘s name, but *directly* on the file name: Doing so, its name appears in the name field as expected, but nothing is saved on clicking save. If you first select the diretory name and then the file name, the bug does not show up here, too. It is as if the system misses to change into the correct directory, even though the direct selection of the file name is a more specific selection, which I would expect to trigger the implicit, less specific selection of the directory, especially as the name does change to the selected file name, as expected.
Bug confirmed. Version: 6.3.0.0.alpha0+ (x64) Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 Locale: zh-TW (zh_TW); UI-Language: en-US Calc: threaded Bug not reproducible in version 6.3.0.0.alpha0+ (x64)
@a.joensson@web.de: please make a screencast @Inoriona": please clarify, is "Bug confirmed" or "Bug not reproducible".
Dear a.joensson, 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
Dear a.joensson, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp