Unix has pretty weird semantics with symlinks and "..". There is generally confusion about whether ".." should remove the previous path component, or if it should go to the parent directory of the directory the symlink points to. (Even bash's autocompletion gets confused about it... it shows different behavior when completing a path prefix, or a path with globbing '*' in it.) The KDE file open dialog and kate seem to disagree about this as well. If you change into a symlink'ed directory, and enter "../" in the filename text field, it'll follow Unix semantics. But when trying to open such a path, kate applies alternative semantics, and opens a file that doesn't exist. Reproducible: Always Steps to Reproduce: 1. "ln -s /etc/ ~/foo" 2. Go into file open dialog in kate, change to the home dir, enter "foo/../ 3. Observe how the text dialog provides suggestions in "/" (the parent directory of /etc), instead of the home dir (what you would get if you remove the "foo/" component) 4. Select an existing file in the text field 5. Confirm how this relative path points to an existing file by e.g. running "stat path" in bash 6. Click the "Open" button 7. Observe how kate "flattened" the path using different semantics, and doesn't open the file you selected. Expected Results: kate/KDE should provide consistent behavior. Unix semantics would be more correct, alternative semantics are less confusing - more importantly, no matter which you pick, it should be consistent.
Confirmed. Arch Linux 64-bit Kate 16.04.2 KDE Frameworks 5.22.0 Qt 5.6.1 xcb wm
Hmm, I just tried that with this test setup: cullmann@jibril:~$ mkdir -p test/lala cullmann@jibril:~$ ln -s test/lala/ lulu cullmann@jibril:~$ cd test/lala/ cullmann@jibril:~/test/lala$ touch 1 2 3 I opened Kate in my home directory and typed in the file dialog: lulu/../lala/1 => yes, can confirm, doesn't work :/
Git commit e762f14c520e1a1eb941dd6c8ce0201ebd4e1b8f by Christoph Cullmann. Committed on 14/07/2019 at 12:39. Pushed by cullmann into branch 'master'. proper filename canonicalization this handles symlinks in paths + .. correctly M +5 -6 addons/lspclient/lspclientserver.cpp M +14 -9 kate/katedocmanager.cpp https://commits.kde.org/kate/e762f14c520e1a1eb941dd6c8ce0201ebd4e1b8f
Btw., thanks for the detailed report!
Thanks. Strangely, it doesn't work if the second path component starts with a ".". For example, creating a symlink to some other directory in the home directory, entering though this symlink in the file open dialog, and trying to open "../.config/katerc" shows a file not found warning dialog, even though the file exists. But this warning dialog is created by the Qt file dialog (which qt5ct forces instead of the KDE dialog for who knows which reason), so this isn't kate's problem. Independent of that, is there any chance that the behavior could be changed _not_ to expand symlinks in any situation?
I think not expanding symlink leads to a lot of other problems like duplicated opened files, as at the moment many parts assume the "url" is canonical. I would not really want to touch that.