Buggy behaviour with multiple views of same file across multiple windows causing data loss #2870
There is an issue when working with multiple tabs of the same file across multiple windows. When the issue occurs, tabs across two windows pointing to the same file are unaware that they are working on the same file. Updates to one tab will not be reflected in the other until the other tab is activated, at which point a reload occurs.
It is possible to make edits to both of these tabs independently. Because out-of-sync tabs are only reloaded after a window is activated, the content of these tabs can diverge significantly. If changes are made to both tabs, and one tab is saved, the other tab will reload, causing all data entered in that tab since the divergence to be lost. If it has been a while since one tab was activated (eg. an hour or so), the data loss can be significant. Saving regularly does not in any way mitigate this loss. It is also not obvious that the issue has occurred, meaning that the data loss may not be discovered until much later.
This makes working on the same file across multiple windows dangerous to use. Because there is no way to tell that the situation has occurred, it makes using multiple windows risky unless you are carefully watching the tabs you open in each window.
The problem is compounded if one tab has unsaved changes and you activate a tab in a second window.
Steps to reproduce
Multiple tabs open to the same view should exhibit the behaviour expected when opening multiple views into the same file, ie. immediate updates, no reload required.
The tabs de-sync as described above and significant data loss is possible if the tabs are edited and saved in the incorrect order.
I'm not familiar with the code, but I'm going to guess that there needs to be a check added when a tab is created (via any of the methods listed) that checks if the file is already opened. If so, the file is opened via clone_file instead.
Workaround without a fix involves remaining aware of the issue and avoiding it when possible. When it comes up, you close one of the tabs, clone the other, and drag it to the new window. This tends to lose the current file position, and is cumbersome to do repeatedly.
Looks like there's a bit of history to this bug, which is concerning considering the potential for data loss.
Incidentally, in solving a similar problem for a project of mine (not a text editor, but it also worked on files) I converted all filenames into absolute paths in an unambiguous fashion (eg. converting to use the same slashes, collapsing ".." entries). Popped that into a hash and then I had a way to determine if something is referring to the same file. Alternatively, under Linux at least, stat() populates a structure where st_ino (the inode) can be used to determine if two things are pointing to the same file. For Windows, GetFileInformationByHandle and nFileIndexHigh/Low appear to serve a similar function, though I've never used them myself.
I imagine a similar approach could be used by Sublime. I hope this helps.