Bug 318696 - Kate should resolve canonical path to check if a file is already open
Summary: Kate should resolve canonical path to check if a file is already open
Status: RESOLVED FIXED
Alias: None
Product: kate
Classification: Applications
Component: application (show other bugs)
Version: 3.10.2
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-22 02:34 UTC by Shriramana Sharma
Modified: 2014-09-23 18:28 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Sample directory tree demonstrating this bug (288 bytes, application/gzip)
2013-04-22 02:34 UTC, Shriramana Sharma
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Shriramana Sharma 2013-04-22 02:34:25 UTC
Created attachment 79366 [details]
Sample directory tree demonstrating this bug

Kate currently does not resolve canonical path of a file to check whether it's already open. This causes a problem in symlinked filetrees where Kate opens multiple copies of the same file, and editing one copy and saving causes the "This file has been modified" dialog to popup. This is at least annoying, and at worst, perhaps it may lead to one overwriting ones own changes because the same file is multiply open.

For instance, on my system my home dir /home/username is actually a symlink to a directory on another partition. I have about 15 source code files open at a time when I'm working on my project so often I don't notice which file is already open. If I double click on a file in Dolphin to open it in Kate, depending on via which path I'm looking at the directory the same file may get opened again even if it was already opened before via a different path. And if I make some changes and save, I get the "File modified" dialog.

It would seem that a simple string comparison is being used to test whether a file is already opened or not. Since QFileInfo provides canonicalFilePath, I hope it would not be difficult to resolve the canonical path for the same.

BTW this problem exists both in the case of dir symlinks and file symlinks. Examples for both can be found in the attached tarballed directory.

Please fix this. Thank you.
Comment 1 Christoph Cullmann 2014-09-23 18:28:40 UTC
Author: Christoph Cullmann <cullmann@kde.org>  2014-09-09 23:05:10
Committer: Christoph Cullmann <cullmann@kde.org>  2014-09-09 23:05:10
Parent: 15c7c706654bbab135e1511ee35c1581cac401da (add hint in which menu the read-only option is)
Child:  e510c15f73b2d5243a739b24394b4c73ed14ffdb (emacs mode :))
Branches: master, remotes/origin/master
Follows: v4.100.0-rc1
Precedes: 

    normalize local file paths
    BUG: 330435