Bug 339061

Summary:	Inconsistency with ".." and symlinks in file open dialog
Product:	[Applications] kate	Reporter:	nfxjfg
Component:	application	Assignee:	KWrite Developers <kwrite-bugs-null>
Status:	RESOLVED FIXED
Severity:	minor	CC:	christoph, ilmari.lauhakangas
Priority:	NOR
Version First Reported In:	16.04.1
Target Milestone:	---
Platform:	Debian unstable
OS:	Linux
Latest Commit:	https://commits.kde.org/kate/e762f14c520e1a1eb941dd6c8ce0201ebd4e1b8f	Version Fixed In:
Sentry Crash Report:

Description nfxjfg 2014-09-14 09:03:40 UTC

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.

Comment 1 Buovjaga 2016-06-19 13:32:18 UTC

Confirmed.

Arch Linux 64-bit
Kate 16.04.2
KDE Frameworks 5.22.0
Qt 5.6.1
xcb wm

Comment 2 Christoph Cullmann 2019-07-14 12:31:14 UTC

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 :/

Comment 3 Christoph Cullmann 2019-07-14 12:39:44 UTC

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

Comment 4 Christoph Cullmann 2019-07-14 12:40:50 UTC

Btw., thanks for the detailed report!

Comment 5 nfxjfg 2019-07-16 14:31:39 UTC

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?

Comment 6 Christoph Cullmann 2019-07-16 14:45:21 UTC

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.