|Summary:||kfiledialog does not remember settings|
|Product:||[Applications] kfile||Reporter:||Ferdinand Gassauer <gassauer>|
|Component:||general||Assignee:||kdelibs bugs <kdelibs-bugs>|
|Severity:||normal||CC:||adaptee, agateau, annma, m.wege, niels.misc|
|Latest Commit:||http://commits.kde.org/kdelibs/c59c20a325098a55387544c7b670a5ca075d94ba||Version Fixed In:||4.11.0|
|Bug Depends on:|
Description Ferdinand Gassauer 2007-01-01 19:57:46 UTC
Version: (using KDE 3.5.5, compiled sources) Compiler: Target: x86_64-suse-linux OS: Linux (x86_64) release 18.104.22.168-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.
Comment 1 Ferdinand Gassauer 2007-01-01 19:58:44 UTC
sorry * Show Speedbar=false/false should read * Show Speedbar=false/true
Comment 2 Carsten Pfeiffer 2007-01-01 21:52:14 UTC
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
Comment 3 Ferdinand Gassauer 2007-01-01 22:51:45 UTC
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.
Comment 4 Ferdinand Gassauer 2007-01-01 22:56:43 UTC
I observed the directory during KDE-startup and saw also a knotify<yyy>.new for a short time.
Comment 5 Carsten Pfeiffer 2007-01-02 08:49:52 UTC
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
Comment 6 Ferdinand Gassauer 2007-01-02 12:54:52 UTC
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"?
Comment 7 Carsten Pfeiffer 2007-01-02 23:56:33 UTC
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
Comment 8 Ferdinand Gassauer 2007-01-03 06:35:37 UTC
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"
Comment 9 Ferdinand Gassauer 2007-01-03 06:40:56 UTC
> 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.
Comment 10 Carsten Pfeiffer 2007-01-03 20:02:10 UTC
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.
Comment 11 Carsten Pfeiffer 2007-01-03 20:15:02 UTC
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).
Comment 12 Ferdinand Gassauer 2007-06-24 09:16:23 UTC
still in 3.5.7
Comment 13 Christoph Feck 2009-08-27 02:37:22 UTC
Moving from "kio/kfile" component to "kfile" product, helps sorting out duplicates.
Comment 14 Christoph Feck 2011-06-20 02:19:49 UTC
*** Bug 276091 has been marked as a duplicate of this bug. ***
Comment 15 m.wege 2012-02-11 22:50:49 UTC
This bug is still present in KDE 4.8
Comment 16 Anne-Marie Mahfouf 2012-02-13 09:56:18 UTC
- 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...
Comment 17 m.wege 2012-09-13 23:47:52 UTC
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?
Comment 18 Aurelien Gateau 2012-09-26 16:20:53 UTC
Just filed a review request to fix this bug: https://git.reviewboard.kde.org/r/106581/
Comment 19 Aurelien Gateau 2013-06-10 17:24:05 UTC
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
Comment 20 Aurelien Gateau 2013-06-10 17:24:05 UTC
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