Bug 139475 - kfiledialog does not remember settings
Summary: kfiledialog does not remember settings
Status: RESOLVED FIXED
Alias: None
Product: kfile
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
: 276091 (view as bug list)
Depends on:
Blocks: extramile
  Show dependency treegraph
 
Reported: 2007-01-01 19:57 UTC by Ferdinand Gassauer
Modified: 2013-06-10 17:24 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.11.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 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.
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