Version: (using KDE KDE 3.1.1) Installed from: Compiled From Sources OS: Linux When you change directory in Konsole using "cd" and the directory (say "/home/user/link") is acually a link to "/home/user/target", PWD will say you are in /home/user/link. When you change directory in Konqueror by clicking on it and the directory (say "/home/user/link") is acually a link to "/home/user/target", the address bar will say you are in /home/user/target. This is inconsistent and confusing to unexperienced Linux users. As a system administrator, I want to be able to create links to /mnt/diskxxx for example and I want these links to be transparent to the users. Users tend to get confused if they get redirected to /mnt/. They think they're in the wrong spot, as they have left their home directory.

Agreed. I've actually seen this confuse some people.

On Tuesday 07 March 2006 20:46, Andras Mantia wrote: > Hi, > > I expect this to be a controversial patch, but it is needed to achieve > consistency within Konqueror itself. The problem is described in > http://bugs.kde.org/123230 . The reason why I changed here and not in > the sidebar is because it would be still inconsistent, as the user > could enter the directory by typing the path in the location bar. > I have no idea why the symlink resolving was needed, maybe it was > useful when running applications, but KFileItem::run anyway uses the > destination, not the link. Well if you follow the comment and read KFileItem::run you can see that: // When clicking on a link to e.g. $HOME from the desktop, we want to open $HOME Imagine you have a link to your home on the desktop called "MyHome", when clicking on it you don't want to see "/home/user/Desktop/MyHome/" in konqueror, but /home/user. So how do we solve this? In one case a symlink is used to hide the actual location of a directory (/mnt) and in the other case the actual location (home) *is* where we want to go, the symlink is just a convenient way to go there. Do we need a desktop-specific hack (making symlink-resolution happen only if the link is on the desktop), or does someone have a better idea?

*** Bug 123230 has been marked as a duplicate of this bug. ***

On Thursday 09 March 2006 12:08, David Faure wrote: > making symlink-resolution happen only if the link is on the desktop ... is done in the attached patches. Of course when going to ~/Desktop/ in konqueror, then clicking on a link to $HOME leads to /home/dfaure/Desktop/myhome, but I guess that's fine, it gives a consistent behavior in konqueror, and another one on the desktop (not the first time...) Created an attachment (id=15024) [details] kfileitem.cpp.diff Created an attachment (id=15025) [details] libkonq.diff

Just for the record post my answer here as well: > Well if you follow the comment and read KFileItem::run you can see > that: // When clicking on a link to e.g. $HOME from the desktop, we > want to open $HOME I read it but it wasn't clear. > Imagine you have a link to your home on the desktop called "MyHome", > when clicking on it you don't want to see > "/home/user/Desktop/MyHome/" in konqueror, but /home/user. Hm, I missed this issue. > So how do we solve this? In one case a symlink is used to hide the > actual location of a directory (/mnt) and in the other case the > actual location (home) *is* where we want to go, the symlink is just > a convenient way to go there. Do we need a desktop-specific hack > (making symlink-resolution happen only if the link is on the > desktop), or does someone have a better idea? The current behavior is very confusing for a normal user and as I wrote it is inconsistent as well. So unless there is abetter idea I support the desktop-specific hack. Andras

I would rather propose to only resolve symlinks that point to places inside $HOME. This way, other 'scary places' outside $HOME will always be hidden and appear to live inside $HOME. The user will never be taken outside $HOME.

I tested and like David's solution. From my point of view you can commit.

Dik: having a different behavior for links on the desktop makes sense to me (it's already the case for showing the Name field of .desktop files, etc.). Having a different behavior depending on the target of the symlink makes little sense though. If /opt is made a symlink to /mnt/something/ia64/opt, then for the same reasons as those described in this bug report, the user should only see /opt in Konqueror.

SVN commit 517437 by dfaure: Don't resolve links in konqueror, but still resolve them on the desktop. BUG: 63014 M +12 -1 kfileivi.cc M +0 -3 konq_dirpart.cc --- branches/KDE/3.5/kdebase/libkonq/kfileivi.cc #517436:517437 @@ -29,6 +29,7 @@ #include <kiconeffect.h> #include <kfileitem.h> #include <kdebug.h> +#include <krun.h> #undef Bool @@ -344,7 +345,17 @@ void KFileIVI::returnPressed() { - m_fileitem->run(); + if ( static_cast<KonqIconViewWidget*>(iconView())->isDesktop() ) { + KURL url = m_fileitem->url(); + // When clicking on a link to e.g. $HOME from the desktop, we want to open $HOME + // Symlink resolution must only happen on the desktop though (#63014) + if ( m_fileitem->isLink() && url.isLocalFile() ) + url = KURL( url, m_fileitem->linkDest() ); + + (void) new KRun( url, m_fileitem->mode(), m_fileitem->isLocalFile() ); + } else { + m_fileitem->run(); + } } --- branches/KDE/3.5/kdebase/libkonq/konq_dirpart.cc #517436:517437 @@ -318,9 +318,6 @@ args.serviceType = fileItem->mimetype(); args.trustedSource = true; - if ( fileItem->isLink() && fileItem->isLocalFile() ) // see KFileItem::run - url = KURL( url, KURL::encode_string( fileItem->linkDest() ) ); - if (KonqFMSettings::settings()->alwaysNewWin() && fileItem->isDir()) { //args.frameName = "_blank"; // open new window // We tried the other option, passing the path as framename so that

Ok, I'm fine with the changes.