Cloned file status breaks after N++ restart

[Alan Kilborn]

Try this, in 8.7.9:

• Press Ctrl+n to create a new tab (new 2 appears, for example)
• Modify the tab by typing a few random characters
• Right-click the tab, choose Move Document > Clone to Other View (editing viewport splits and now two tabs are visible with captions of new 2)
• Type a few more random characters (see that the new typing is appearing in both tabs)
• Exit and restart Notepad++
• Type yet more random characters into one of the new 2 tabs (see that the new typing is NOT appearing in both new 2 tabs)

Does anyone else see this as a bug?
I’d think that the cloned status of a file should persist over a restart.
Additionally, in the scenario supplied, the result is two samed-named tabs (normally this is a “not permitted” state) exist concurrently.

[mkupper]

@Alan-Kilborn said in Cloned file status breaks after N++ restart:

Does anyone else see this as a bug?

I’d agree that seems like a bug. The backupFilePath values are identical in the <File ...> records in for both the main and secondary views within session.xml. Thus, Notepad++ should be able to detect that it’s a cloned file and to set up the internal linkage so that changes to one of the clones are reflected in the other(s) in real time.

As they are sharing the same backup file there is some “cloning” in that you can type in one of the tabs, exit/restart Notepad++, and the new material appears in both tabs.

Another issue is that if you close the former clone/tab (picking No to the save prompt) and then exit Notepad++ then Notepad++ reports

---------------------------
Save
---------------------------
Your backup file cannot be found (deleted from outside).
Save it otherwise your data will be lost
Do you want to save file "new 2" ?
---------------------------
Yes   No   Cancel   
---------------------------

If you pick Yes then it will want to save this as a normal file.
If you pick No and then exit/restart Notepad++ then Notepad++ pops up:

---------------------------
File inaccessible
---------------------------
Some files from your past session are inaccessible. They can be opened as empty and read-only documents as placeholders.

Would you like to create those placeholders?

NOTE: Choosing not to create the placeholders or closing them later, your session WILL BE MODIFIED ON EXIT! We suggest you backup your "session.xml" now.
---------------------------
Yes   No   
---------------------------

[Alan Kilborn]

@mkupper said:

Notepad++ should be able to detect that it’s a cloned file and to set up the internal linkage so that changes to one of the clones are reflected in the other(s) in real time.

I suppose this could happen, but it seems like it would be simpler for Notepad++ to note the fact of a clone when it writes the session file, and then of course when it reads the session file at next startup it could prepare the cloning state.

[Coises]

I don’t use sessions, nor do I ordinarily have any backup options enabled, but as a test I enabled and tried with a debug compilation. For what it’s worth, the glitch appears to happen here:

https://github.com/notepad-plus-plus/notepad-plus-plus/blob/a23955742cd4422b2365d6fde7a82b4ff0311bd2/PowerEditor/src/NppIO.cpp#L2536

Before checking to see if a file to be opened in the secondary view is a duplicate of a file in the first view, the code first checks to see if the file exists. Since “new 1” doesn’t exist, the check isn’t performed.

[Mark Olson]

@Alan-Kilborn said in Cloned file status breaks after N++ restart:

Does anyone else see this as a bug?

Not only is this a bug, I’m pretty sure it was a regression. IIRC this bug was fixed a few months ago. No idea why it’s broken again.

[Alan Kilborn]

I opened an official bug report on this: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/16412

[xomx]

@Mark-Olson said in Cloned file status breaks after N++ restart:

this a bug, I’m pretty sure it was a regression. IIRC this bug was fixed a few months ago.

Can you point me to that previous fix, I could not find that?

[Mark Olson]

@xomx
As far as I can tell this commit is the most recent fix.

[xomx]

@Mark-Olson

Thanks, I used that info while fixing: x64 Release binary for testing