is this temp file subsequently deleted or overwritten?

(In reply to tommy27 from comment #1)
> is this temp file subsequently deleted or overwritten?

I can be a bit more specific after looking more closely at the output. The change in the color picker initializes a registrymodifications.xcu update. The change is written into a *.tmp file, renamed to registrymodifications.xcu after a successful save. The process takes up +/- 1 millisecond

To be more precise, the registrymodifications.xcu update is related to two settings: RecentColor and RecentColorName

<item oor:path="/org.openoffice.Office.Common/UserColors"><prop oor:name="RecentColor" oor:op="fuse"><value>0</value></prop></item>

<item oor:path="/org.openoffice.Office.Common/UserColors"><prop oor:name="RecentColorName" oor:op="fuse"><value><it>Black</it></value></prop></item>

About the expected results, because it has a purpose seen in the light of comment 3:

Probably a (changeable) interval based save. 
1. Re-saving registrymodifications.xcu on every change seems to be a bit excessive to me (especially because of the increasing file size when using different applications within the LibO suite). It will end op writing around 400kb every time when touching the highlight or color button (for example; there are more cases)
2. Being smart an hold of saving until LibO closes isn't that ideal either. For example when LibO is crashing or for debugging purposes.

Hi Telesto,
is this issue still reproducible in master ?

Still the same
Version: 6.3.0.0.alpha0+
Build ID: d71ea82055a6a304493c7eaa90809a348e23784d
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-11-19_03:25:07
Locale: en-US (nl_NL); UI-Language: en-US
Calc: CL

Hi Telesto,
any chance this could be bisected ?

(In reply to Xisco Faulí from comment #7)
> Hi Telesto,
> any chance this could be bisected ?

ping ?

Not sure if there is much to gain from it.. It's more a global design problem I guess.. The xcu is immediately updated on every change (floating dialogs, colors, window position etc). As such acceptable (but not ideal) if the xcu isn't to large. However this isn't the case. A xcu size of 2-4 MB isn't to exceptional causing a crazy amount of disk activity storing mostly trivial things

Lazy writing of xcu would be a solution. So storing a some intervals. Release build only of course as I might be problematic for debugging.
Another solution would be splitting settings to different xcu's but half-house solution; probably not desired anyway (backward compatibility ) 

It needs a Dev Evaluation IMHO

anyway, a bisection would be really helpful here

Bisected to:
author	Rishabh Kumar <kris.kr296@gmail.com>	2016-07-29 18:39:46 +0530
committer	Rishabh Kumar <kris.kr296@yahoo.in>	2016-07-29 14:52:56 +0000
commit 7f262a41017685709c288b57c8f03244e8c6149e (patch)
tree 130677ce67e64e47ab6341fa59a9ecac8fae2b63
parent bb01247f71a46fb7cae18b51516096adfd059bbc (diff)
[GSoC] Fix recent colors in color popup widget
Save recent colors in user configuration.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=7f262a41017685709c288b57c8f03244e8c6149e

I started thinking the current behaviour is just fine and asked on dev chat. Noel replied: "I can't see that being a worthwhile performance improvement (i.e. the extra code complexity is not worth the gain)"

(In reply to Buovjaga from comment #13)
> I started thinking the current behaviour is just fine and asked on dev chat.
> Noel replied: "I can't see that being a worthwhile performance improvement
> (i.e. the extra code complexity is not worth the gain)"

But what did you ask specifically? It's not about performance; so reducing speed. (at least not on SSD). This more about causing disk activity. So 'write' actions. They XCU is re-written over and over for every color change..

And that's only they limited context. It's actually written on so many occurances. Shrink a dialog, opening a file, opening context depend menu. Repositioning the dialog. Making toolbar floating.. Changing a setting. Maybe even which window is on top. 

And writing is done separate thread so you don't notice. Except for those who do roaming of some kind (there is ask somewhere) where every profile is saved on central service.

So topic is more about causing huge disk activity (writing). And in context could contribute to wearing SSD's/ flash cards or whatever used for storage. where also they size of they drive matters and and such. 

Yes, browser cache tends to do pretty much the same. But this is a 'stupid' XCU. Based on file size it would fit into memory easily (i'm might grump at high Memory usage at once in a while, but in this case I would make sense :-)
Except there will happen if LibreOffice crashes. Partly solved by interval saving (1 - 2 minutes). However their must be override, as this was problematic for debugging.

Another alternative I proposed was SQLite (somehow not here, but assume similar context). However the advantage was doubted (even SQLite advertising about this )

(In reply to Telesto from comment #14)
> And that's only they limited context. It's actually written on so many
> occurances. Shrink a dialog, opening a file, opening context depend menu.
> Repositioning the dialog. Making toolbar floating.. Changing a setting.
> Maybe even which window is on top. 

Yes, and all of this saving prevents loss of data. Why would you want to make it more risky?

(In reply to Buovjaga from comment #15)
> (In reply to Telesto from comment #14)
> > And that's only they limited context. It's actually written on so many
> > occurances. Shrink a dialog, opening a file, opening context depend menu.
> > Repositioning the dialog. Making toolbar floating.. Changing a setting.
> > Maybe even which window is on top. 
> 
> Yes, and all of this saving prevents loss of data. Why would you want to
> make it more risky?

If it would be critical stuff of course not, but window position and last used color or last setting doesn't belong to 'needs to preserved at all costs'. For me trade fair trade-off between disk activity and preserving settings. IMHO. And LibreOffice isn't supposed to crash anyhow :-).

BTW: would be nice if you add the chatlog or directly let people comment in the bugtracker.. not big fan of 'second hand' info. People have managed to bend the topic to the desired answer (not saying you do, but people managed to do that so bit skeptical nowadays).

And I personally like some splitting. They topic between. If writing seen not problematic at all; or nothing wrong with it. Or that more about development costs/benefits.

Or what you're suggestion about 'losing' settings.  

You can argue, does it matter. And they answer for me is; yes. As gives insight what the considerations are. How people are thinking. 

Because this can't happen because we will lose 'some data' - as far i'm aware - user settings data not being 'super convincing'. Or even bit sad, actually.
So it's or about proofing data being critical; or costs/benefits. Or about who cares about 2,5 MB writes 2000 a day 365 a year. 

Anyhow still curious how they online variant manages this. I assume this doesn't happen there, else would not really nice for they server I guess

(In reply to Buovjaga from comment #15)
> Yes, and all of this saving prevents loss of data. Why would you want to
> make it more risky?
Considering LO doesn't save the document after each keypress, I'm not sure saving various last-set config values is actually a case of preventing loss of data.

And if the following situation mentioned by Telesto is true, saving megabytes so often is far from great: "A xcu size of 2-4 MB isn't to exceptional causing a crazy amount of disk activity storing mostly trivial things"

(In reply to Aron Budea from comment #17)
> (In reply to Buovjaga from comment #15)
> > Yes, and all of this saving prevents loss of data. Why would you want to
> > make it more risky?
> Considering LO doesn't save the document after each keypress, I'm not sure
> saving various last-set config values is actually a case of preventing loss
> of data.
> 
> And if the following situation mentioned by Telesto is true, saving
> megabytes so often is far from great: "A xcu size of 2-4 MB isn't to
> exceptional causing a crazy amount of disk activity storing mostly trivial
> things"

FWIW: there are likely by far more instances where it's written. You can you process monitor to check or read the XCU itself they look what's stored.

Noel his position if it it doesn't hurt performance it's no issue (or lets say no big deal) and hard disk are design to handle lots of writes.

Which isn't untrue. And we can add a there likely more unoptimized programs; and there are other instances where stuff is written to temporal files and such.

And we can argue about they load at desktop for typical office desktop. And replacement schedule (in the Western world). So hitting they maximum writes not likely to happen

Or we can also argue against they developing country's. Where assume cloud solutions not being they obvious choice (yet); price/quality of the internet connection. People working with far older (second/third hand) systems, I assume.

If it's easy to prevent, it might be wise to do so. They costs are in they area of more code complexity and more stuff which can break down. And no auto-save stuff is hard to verifier to (Luke Kendall still encountering kind of timer issue with auto-save; kicking in to often once in a while. But time consuming business to track down).

So there is a trade-off here. They whole timer stuff can of course be prevented by saving they xcu in a SQLite database (assuming it does make true what's advertised about reducing writes). But objection here likely be plain xml is 'easier' to access with an editor compared to dumping it into a SQLite database. And of course they downside of updating another external package. An advantage would be that the size of they sqlite should be smaller (as there a columns so non repetitive xml markup stuff)

And there are some other area's where SQLite would be nice (see Julien: bug 134421)

There is no straightforward answer to this, IMHO. Depends on what's valued. It's surely not something most users will notice if changed. So the achievement here isn't unique selling point. More topic out of principle

Ok then

Dear Telesto,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug