Version: (using KDE 3.5.5, compiled sources) Compiler: Target: x86_64-suse-linux OS: Linux (x86_64) release 2.6.18.2-34-default Hi! I want to keep * detailed view * show quick access panel but it does not happen, Now I found that I have 1-2 kdeglobals<WJHFDa>.new files a day mainly differing in * History Items (not surprising) * recent URLs (not surprising) * Show Speedbar=false/false * View Style=Simple/Detail and a section - which is NOT in the kdeglobals at all. [Paths] Trash=$HOME/Desktop/Trash/ where do thes many kdeglobals*.new files come from? It looks like that the kdeglobal file form the distribution is used instead of the users kdeglobal.
sorry * Show Speedbar=false/false should read * Show Speedbar=false/true
On Monday 01 January 2007 19:57, Ferdinand Gassauer wrote: > Now I found that I have 1-2 > kdeglobals<WJHFDa>.new files a day mainly differing in [...] > where do thes many kdeglobals*.new files come from? Usually that means that there is a problem writing to the existing kdeglobals file, e.g. due to a permission problem. Can you try to change the file manually with an editor? And if that works, can you run some application with strace and see if there is a problem with renaming kdeglobalsXXX.new after you change the kfiledialog configuration? Cheers, Carsten
all files in .kde/share/config are writable by the user. I closed the KDE session, deleted *.new and restarted KDE. first try: I got a kmix<yyyy>.new second try: I got a kdeglobal<yyyy>.new which vanished after some minutes. I was not accessing the kfiledialog actively, but only opening konsole, kmail and konqueror. So it looks more like to be a background process which makes *.new files and is not abel to copy them back in time. I'll keep an eye on this.
I observed the directory during KDE-startup and saw also a knotify<yyy>.new for a short time.
On Monday 01 January 2007 22:51, Ferdinand Gassauer wrote: > So it looks more like to be a background process which makes *.new files > and is not abel to copy them back in time. AFAIK this is normal behavior: when you change a configuration entry with KConfig and then save the configuration, KConfig (KSaveFile) creates and writes a new file (.new) and then renames it to the real filename. This is in order to prevent corrupt files, when the application crashes during the writing. So, something seems to be wrong with the renaming. (strace should be able to verify this) Cheers, Carsten
strace produces huge output and I would have to run all apps with strace because I suspect that it is not kfiledialog causing the problem, because the settings change without my intervention. so please one more question. what happens if more then ONE process tries to modify the same config file (which is more likely for kdeglobals) - is this handled corretcly (locking, serializing)? which one "wins"?
On Tuesday 02 January 2007 12:54, Ferdinand Gassauer wrote: > strace produces huge output and I would have to run all apps with strace > because I suspect that it is not kfiledialog causing the problem, because > the settings change without my intervention. I thought this happens not only on KDE startup, but for every single KDE application? I.e. if you just run kedit, open the filedialog, configure it and close kedit, kdeglobals is wrong. Or did I misunderstand this? BTW, you can limit strace's output with the -e switch, e.g. strace -e rename kedit would only show all occurrences of the rename system call. > what happens if more then ONE process tries to modify the same config file > (which is more likely for kdeglobals) - is this handled corretcly (locking, > serializing)? which one "wins"? AFAIK there is no locking. Cheers, Carsten
Hmm! I put it wrong - sometimes the settings for kfiledialog change WITHOUT intervention in kfiledialog. that is I have stored (used last time) * Show Speedbar=true * View Style=Detail and kfiledialog opens with * Show Speedbar=true * View Style=Simple that what I mean with "does not remember"
> what happens if more then ONE process tries to modify the same config file > (which is more likely for kdeglobals) - is this handled corretcly (locking, > serializing)? which one "wins"? AFAIK there is no locking. Do you know where the > [Paths] > Trash=$HOME/Desktop/Trash/ section comes from ? it's never in the "kdeglobals*.new" file, but only in the kdeglobals.
On Wednesday 03 January 2007 06:40, Ferdinand Gassauer wrote: > Do you know where the > > > [Paths] > > Trash=$HOME/Desktop/Trash/ > > section comes from ? Probably from the "Paths" ("Pfade") kcontrol module.
On Wednesday 03 January 2007 06:35, Ferdinand Gassauer wrote: > I put it wrong - sometimes the settings for kfiledialog change WITHOUT > intervention in kfiledialog. > > that is > I have stored (used last time) > * Show Speedbar=true > * View Style=Detail > > and kfiledialog opens with > * Show Speedbar=true > * View Style=Simple > > that what I mean with "does not remember" This is really weird. This could only happen if the KFileDialog settings were somehow reset to its defaults. This would happen if 1) the kdeglobals file would be deleted 2) some bug was introduced into KFileDialog's classes 2) could be verified by checking the kdeglobals file as soon as you see that the filedialog is messed up again (i.e. don't close the filedialog before checking kdeglobals). If there *is* an erroneous [KFileDialog Settings] group, then KFileDialog must have written it at some point. If there is none, it must have been erased, e.g. by deleting kdeglobals, like in 1).
still in 3.5.7
Moving from "kio/kfile" component to "kfile" product, helps sorting out duplicates.
*** Bug 276091 has been marked as a duplicate of this bug. ***
This bug is still present in KDE 4.8
- kdiroperator works as expected as the test shows meaning it writes and reads the config settings correctly. - if I set Sorting: by Size the config is written correctly but at new open, the GUI messes with it and resets to default which is Sorting: by Name and this is written in the config files. Same for ShowHiddenFiles and other config settings. The View setting is more complicated to explain but basically any config is applied and written but not kept at next opening. Not sure if I explained this correctly...
May be this bug qualifies as an extra mile bug? https://bugs.kde.org/show_bug.cgi?id=303462 If so, could someone who has the rights, add this to it?
Just filed a review request to fix this bug: https://git.reviewboard.kde.org/r/106581/
Git commit 8f2d143edce47ced058cf0cb95644f8147159167 by Aurélien Gâteau. Committed on 26/09/2012 at 17:32. Pushed by gateau into branch 'master'. Use the correct way to save changes to kdeglobals Previous code was writing directly to kdeglobals, which prevented the other KConfigGroup instances from being aware of the changes. M +12 -15 kfile/kfilewidget.cpp http://commits.kde.org/kdelibs/8f2d143edce47ced058cf0cb95644f8147159167
Git commit c59c20a325098a55387544c7b670a5ca075d94ba by Aurélien Gâteau. Committed on 10/06/2013 at 19:23. Pushed by gateau into branch 'master'. Merge branch 'wip/kfiledialog-remember-settings' REVIEW: 106581 FIXED-IN: 4.11.0 http://commits.kde.org/kdelibs/c59c20a325098a55387544c7b670a5ca075d94ba