not needed. Kate 'Recent files' keep the symbolic link references. Reproducible: Always Steps to Reproduce: 1. open file that is accessed through a symbolic link to a folder 2. save and close session close and reopen kate 3. open session Actual Results: (can check session config file) symbolic Link in path is replaced with the real path of the file. Expected Results: I opened a file that is found through a link That is what should be saved in the session not the path produced by following link. Same as 'Recent files' - symbolic link should be still in the path.
*** Bug 387365 has been marked as a duplicate of this bug. ***
John can you please confirm if this still occurs on a recent version of Kate?
Still reproduces with kate 20.08.2. The git project plugin is affected by a similar bug.
Confirmed in comment 3.
This is intentional, sorry. We use close to everywhere the canonical path, already for file open. I am sorry this is not good for your working pattern, but this is the only simple way to ensure we only open files once and are able to easily match stuff. Naturally one could re-design this and try to keep the non-canonical path, but this seems out of scope for this little inconvenience.
> but this is the only simple way to ensure we only open files once and are able to easily match stuff. Interestingly, it doesn't work though. Bind mounts (mount --bind) are not handled. If I open a file and open the same file in a bind mounted directory, the editor still treats them as different files, and gets confused. It even overwrites the changed file without any indication that something is wrong... According to inotifywait, you still get events on both paths, and st_dev/st_ino can be used to uniquely identify a file on a system.
(In reply to nfxjfg from comment #6) > > but this is the only simple way to ensure we only open files once and are able to easily match stuff. > > Interestingly, it doesn't work though. Bind mounts (mount --bind) are not > handled. If I open a file and open the same file in a bind mounted > directory, the editor still treats them as different files, and gets > confused. It even overwrites the changed file without any indication that > something is wrong... > > According to inotifywait, you still get events on both paths, and > st_dev/st_ino can be used to uniquely identify a file on a system. Yeah, you can do all that, but we only identify documents by their URL. Therefore we let Qt compute the canonical file path and be done. Naturally there are X complex ways to still have non-unified paths. But that is for me out of scope,. Even the st_dev/st_ino is actually no good solution, as this isn't stable if you start to delete file that are open and create new ones.
> Naturally there are X complex ways to still have non-unified paths. > But that is for me out of scope,. A half-solution that doesn't solve the full problem (and which wouldn't be a problem to most users), but breaks the workflows of users who want to use symlinks...
(In reply to nfxjfg from comment #8) > > Naturally there are X complex ways to still have non-unified paths. > > But that is for me out of scope,. > > A half-solution that doesn't solve the full problem (and which wouldn't be a > problem to most users), but breaks the workflows of users who want to use > symlinks... That's unfortunately true...