Fist I must say I hate you. I just lost hours of work. I have a calc file to fill and other calc files with data I need to read to fill the first file. I have 2 computers, I run "ssh -X main_computer" from the small computer to open the first file and I want to open other files on the screen of the main computer. Guess what, when I run "libreoffice file.ods" from my main computer it opens it on the screen of the small computer where LibreOffice is already running... Two computers, two screen but I all windows of LibreOffice goes to the same screen... Well I can work so I worked but without this bug I wouldn't have lost my work. Each time I open a file because there are links to other documents it seems LibreOffice thinks the document changed. When I close it, it asks if I want to save BUT THERE IS NO CHANGES. So I say "Don't save" (if I say save, then git wants me to commit changes...). Now you can imagine what happened after hours of work, I closed by mistake the main file I was filling and when it asked me if I want to save, I said "Don't save"... So, don't ask to save a file when nothing changed or we still say "Don't save" when something did change !!! Updating from other files does not mean changes. Try that : * open a file with links to other files * say yes to file links should be updated * save your file and quit * reopen the same file * say again yes to update links * close (Crtl-W) and see, it asks if you want to save even if nothing changed.
Your request is in direct conflict with another request, bug 91345. Adding UX team. Btw., if you continue saying hateful stuff like in your description, I will ban you instantly from the bug tracker.
(In reply to Olivier from comment #0) > ... > * reopen the same file > * say again yes to update links > * close (Crtl-W) and see, it asks if you want to save even if nothing > changed. The program loads the content from the apparently, and doesn't know if that changed.(In reply to Olivier from comment #0) (In reply to Buovjaga from comment #1) > Btw., if you continue saying hateful stuff like in your description, I will > ban you instantly from the bug tracker. Indeed! But possibly is a language problem, where better words to express frustration or so are not known?
(In reply to Buovjaga from comment #1) > Your request is in direct conflict with another request, bug 91345. So the two people have the opposite problem? How can that be.. To me, by the way, it is more natural that a file asks to be saved, after links are updated.
To summarize, you executed a function on a document and expect an evaluation if things really have changed. Sounds not too reasonable to me. There are likely many other situations where this confirmation is needed. Keeping the ticket in NEEDINFO but my take is NOTABUG.
If no data have been changed who cares functions has run? If I modify a value and put back the previous value (without undo) there are still no change and no proposition of saving file should be made. Here is a suggestion, run a SHA1 on the data when you open the file. Run a SHA1 on the data when the user want to quit. If the SHA1 are no the same, ask for saving file, if they are the same, exit. BTW nice to change to NEEDINFO, it reminds me the usual trick to create a commission when you don't want something to be done. So here to reduce the number of bug you convert them to NEEDINFO? Because I cannot see which kind of info you need since I explained and provided an example in my first mail.
(In reply to Olivier from comment #5) > BTW nice to change to NEEDINFO, it reminds me the usual trick to create a > commission when you don't want something to be done. So here to reduce the > number of bug you convert them to NEEDINFO? Because I cannot see which kind > of info you need since I explained and provided an example in my first mail. We try to improve the response time and want to lower the number of tickets where input from UX is requested. Ideally there should be no ticket in state UNCONFIRMED for more than a week. So I could either resolve it immediately as NAB or abuse NEEDINFO as a reminder for myself in case no further input is done. Sorry if you understand this as a "trick".
(In reply to Olivier from comment #5) > If no data have been changed who cares functions has run? If I modify a > value and put back the previous value (without undo) there are still no > change and no proposition of saving file should be made. The thing above is now a completely new request. I just tried reproducing bug 91345 and *it does not ask to save when I close* after only updating links. This is such a mysterious case that I would like to see a screen recording of you opening a file, updating links and closing. Here is one software you could use: http://www.maartenbaert.be/simplescreenrecorder/
Being involved on a similar topic (bug 91345 OS Windows) I would like to make some clarity. 1) Prefixing: - there is the SAVE command (I use it randomly to force saving anyway, regardless of whether it has made any changes or not. It is my habit to close by clicking on "X". - I feel sufficiently tested and verified what said in bug 91345. - It is also my firm opinion that closing a document, in any updated way, is required if you want to save it or not. 2) LIBO adopts different behaviors between Writer and Calc: - ods opened and closed without updating (or any modifications have been nullified): CALC asks always and in any case whether to save YES | NOT, while WRITER does not ask it, simply closes the file leaving it in the preexisting state. I personally feel the CALC mode is more correct. And at this point, I can not fully understand Olivier's problem: - Without specifying the type of file (ods, odt ?) says "Every time I open a file because there are links ..." and later "close (Crtl-W) and see, it asks if you want to save even if nothing changed ": I prove a different experience (see above and see bug 91345 with main.odt and linked.ods). - Say "I closed by mistake ..." and "... do not ask to save a file when nothing changed or we still say" Do not save "when something changed ...". (good-naturedly) ancient Latin said: "Errare umanum est, persevere autem diabolicum!" (to make a mistake is human, but persevering is diabolical). To make no injustice to anyone, for logic and uniformity, I believe that any program, closing a file, should generically ask "if I want to save YES | NOT" by preselecting YES.
@gmarco I can understand saving by default seems logic since saving too much cannot harm... unless you use a versioning system. As I said if the file is saved, then it is different from the previous one even if nothing has changed and therefore git wants me to push it to the repository. So saving whatever is not a good option. If we could have a human readable way to save a file with just the data and no metadata in the file, we could save as much as we want without any impact on the versioning system. It would also be great to see diff between two versions of a file. But you save in a binary mode and I suspect metadata like date of last saving which produce different file even if nothing has been changed. So that's why each time I open a Calc file just to read the data I have to take care to say NO when I ask to quit and it asks me to save the file. Of course each time I open the same file to change things, I would have to say yes if he asked me to save the file, but it never happens since I save manually before I quit. So if it ask me, the answer is always NO unless... I had many windows open and I quit the wrong one, the one with changes. So because LO asks to save unmodified file I have the reflex to say NO and when it asks on purpose because the file has been modified, I still have the same reflex and say NO... Conclusion : don't ask to save an unmodified file or make the saving file a perfect copy of the previous one (git use SHA1 of a file to see if it changed, not the date of last modification). If you call for help everyday because of a wolf but it happens there is no wolf, the day a wolf will attack you, no one will come to help you.
@Buovjaga You said you tried to reproduce without success another and different bug... Don't you think you should ask them to produce you a recording?
@Heiko Tietze ok, so NEEDINFO is just a reminder for you but in the same time the bug reporter says: "This bug is (most likely) in NEEDINFO status because someone has asked for information or data. After you've satisfied the request as best as you can, please leave a comment and change the status back to UNCONFIRMED." so what should I do since you don't ask for more info? Understand it looks like a trick to push a bug report to the Limbo.
Seems folks need a reminder of what actually happens under the hood in LibreOffice. A native ODF document is _not_ "opened" into LibreOffice--rather its XML is read and filters import its elements for rendering to document canvas. The original ODF is set aside to temporary storage (and a lock file may be set). When exiting from the document: -- "saving" the document to ODF _always_ writes a completely new ODF archive--whether any changes were made to the document content or not, the original is destroyed. or -- "closing" the document, from the File -> Close menu, or the "X" widget on the LibreOffice main Menu, or even from the OS/DE Window Manager--LibreOffice will alert to unsaved changes. User is _always_ prompted to Save Document with an alert dialog with button widgets to: Save -- will trigger the filter export to ODF, and will _always_ overwrite the original. Don't Save -- will close the document deleting internal changes, and release the original _always_ unchanged (system security on the file object may show access). Cancel -- will drop the close action and return focus to document canvas. There are other actions for exiting of course--e.g. a "save as" that exposes use of export filters for ODF document formats, or other external formats, but that when used release the original ODF document (and lock) unchanged. The Export choices do the same, but instead keep the document open to canvas (its original ODF held in temp space--a Close -> Don't save would restore it unchanged releasing its lock). But that is it! It works the same in all modules, and functions as is needed consistently for consistent UI. The defaults are sane, and fair warning is given in the alert prior to any loss. WONTFIX
Ignoring any other non-core and subjective discussion, I wish to draw attention to the different behavior between Writer and Calc when ods | odt files are opened and closed without any modifications: - CALC asks always and in any case whether to save YES | NOT, - WRITER does not ask it, simply closes the file leaving it in the preexisting state. I personally feel the CALC mode is preferable but, regardless of subjective opinions, both applications should behave in the same way.
(In reply to gmarco from comment #13) > - CALC asks always and in any case whether to save YES | NOT, It does not. It is allowed to save a spreadsheet that has not been changed, to allow a possible changed view to be saved, so that will be used if the file is opened again.
(In reply to Cor Nouws from comment #14) > (In reply to gmarco from comment #13) > > - CALC asks always and in any case whether to save YES | NOT, > > It does not. I do not understand the negation and the substance: in any case, closing by the shortcut X, Calc asks if you want to save, it seems obvious that the file is saved by replying YES, it is NOT saved by replying NO. The substance is that Calc asks it always and in any case , Writer does not.