KConfigBase::read(List)PathEntry and symlinks
faure at kde.org
Wed Sep 6 15:34:10 BST 2006
On Friday 01 September 2006 20:39, Andras Mantia wrote:
> readPathEntry and readListPathEntry doesn't resolve symlinks in case
> $HOME is a link to somewhere else. I don't know how common it is, but I
> have such a setup. In the case the application deals with resolved
> paths internally and then reads back an entry with the above methods,
> the two paths will not match.
If the app deals with resolved paths internally, then it should probably resolve
paths when writing them out for consistency?
Although this breaks when changing the link to somewhere else (e.g. moving
your home to another partition), so working with resolved paths doesn't sound
like a very good idea over all.
> Would be nice if such resolving could be done on the kdelibs level,
> altough I'm afraid in KDE3 it would break existing applications.
> So what I suggest for KDE4 is:
> - in read/write path entry after getting the $HOME env. var, resolve it
read: that's the third item below
write: not sure what you mean.
> - when writing replace part of the path with the string "$HOME" if the
> path contains the resolved OR unresolved $HOME
OK so cleanHomeDirPath() should realpath(homeDir), and if it gets a different than
homeDir it should look for both in <path>. This sounds like a good idea in any case.
> - in read, always return the resolved path
I disagree with that one. If the user selected a file in /home/foo, he should still
see /home/foo after the app restarts.
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kde-core-devel