Loading Current Session with missing files does not meet user expectation

[pryrt]

Description of the Issue

When you start Notepad++ and it loads the current session, if one or more of the files from the session are "missing" for any reason, those files aren't opened ... so when Notepad++ saves the new current session, those files are removed from the session.

If the files were truly permanently gone (deleted intentionally), that behavior makes sense.

But if the reason the files are gone is because of a temporary problem outside of their control, then the users get confused when those files don't come back into Notepad++ when the temporary problem is resolved. Examples include:

1. the USB drive was bumped and Windows didn't see it was there, so Windows claims the files don't exist even though they are still on the USB stick
2. the network drive was temporarily unavailable or hadn't been fully connected when Notepad++ started looking for the files
3. the user ran in Admin mode temporarily (because run-as-admin doesn't see all mounted network drives)
4. wifi was temporarily unavailable so One Drive or DropBox or similar cloud folders weren't finished downloading files yet
5. any number of other temporary reasons that I couldn't think of off the top of my head

This isn't some hypothetical: Users have been complaining about this more, recently, in the Forum:

• https://community.notepad-plus-plus.org/topic/23380/files-from-sessions-are-lost-when-a-session-file-is-opened-and-not-connected-to-the-vpn-that-was-connected-but-dropped
• https://community.notepad-plus-plus.org/topic/23433/how-to-find-out-what-txt-files-were-open-in-the-last-session

Steps to Reproduce the Issue

0. Start with new portable Notepad++
1. Open files a.txt and b.txt
2. Close Notepad++ so it saves the current session as session.xml
3. Move b.txt to be.txt
4. Open Notepad++: only a.txt is open, because b.txt doesn't exist
5. PROBLEM#1: b.txt is not in File > Recent Files... list.
6. Close Notepad++ so it saves the current session as session.xml
7. Move be.txt back to b.txt
8. Open Notepad++: still only opens a.txt
9. PROBLEM#2: at this point, common users (as given by the two example topics above) expect that b.txt will also be open again; or, barring that, that there's at least a way to see what files used to be open (like the Recent Files History list).

Desired Behavior

Based on my understanding, I think they would appreciate a two-part fix:

1. When session files are non-existent, they should be added to the "Recent Files History" so that Notepad++ has a record of files that used to be open but aren't any more.
2. If the Preferences > Backup settings could have an option called "Keep missing files in the saved session", which would default to ON.

The desired sequence of events:

1. Notepad++ launches
2. Parse the active session.xml
3. For each file, in session:
   • if file exists, open it
   • if file missing,
     1. add it to an internal list of "missing files"
     2. add it to the Recent Files History list
4. (normal editor usage)
5. User triggers closing Notepad++
6. Notepad++ checks "Keep missing files in the saved session" setting:
   • if ON, Notepad++ transfers the "missing files" list into the active session, along with the list of files that are really open
   • if OFF, Notepad++ only includes the files that still exist and are really open
7. Notepad++ closes
8. Next run
   • if option was ON at the last session-save, the files that were "missing" last time but exist again this time are re-opened, so the users files automatically come back once the network glitch is over
   • any files that were "missing" last time and are still missing this time are still listed in the Recent Files History list, so they have a record of what files still aren't reloaded.

Optional suggestion: Keep a missingCount attribute in the session.xml entry for each file. If the file exists when the session is saved, that attribute is set to 0. If the file was "missing" this run of Notepad++, add 1 for that file when the session.xml is saved. When the session is loaded and missingCount is above some threshold (*), permanently delete it from the session file, rather than permanently keeping a deleted file in the session. *: maybe hardcode the threshold at 5, or maybe make the threshold a setting in the preferences dialog, so that users could decide how many times to keep a missing file before finally giving up and removing it from the active session.

Debug Information

Notepad++ v8.4.4   (64-bit)
Build time : Jul 15 2022 - 17:54:42
Path : C:\usr\local\apps\npp\npp.8.4.4.portable.x64\notepad++.exe
Command Line : a.txt b.txt
Admin mode : OFF
Local Conf mode : ON
Cloud Config : OFF
OS Name : Windows 10 Enterprise (64-bit) 
OS Version : 20H2
OS Build : 19042.1889
Current ANSI codepage : 1252
Plugins : 
    mimeTools (2.8)
    NppConverter (4.4)
    NppExport (0.4)

[pryrt]

rereading this post, "VPN problems" is another temporary reason.

And as that user suggested, the same logic/behavior should be implemented when saving manual sessions through File > Save Session... or the automatic-save-of-manual-session that came in v8.2, in addition to the main session.xml behavior.

[ArkadiuszMichalski]

It also affects the manual loading of sessions: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/7931

Same as https://github.com/notepad-plus-plus/notepad-plus-plus/issues/4061 and other.

[pryrt]

Thanks for finding those, @ArkadiuszMichalski ; I searched some in the existing issues, but didn't go beyond the first or second page of matches for "session", so didn't get that far back.

Hopefully my concrete suggestion for an algorithm outweighs my lazy search. ;-)

[alankilborn]

I think users would expect "restored" file tabs to be at their original places in the tab ordering and/or view. I'm mentioning this because it wasn't explicitly stated above.

[umop-apisdn69]

Description of the Issue

When you start Notepad++ and it loads the current session, if one or more of the files from the session are "missing" for any reason, those files aren't opened ... so when Notepad++ saves the new current session, those files are removed from the session.

Why remove the "missing" files from the session file at all? (The removal currently happens immediately when N++ opens the session file, not later. That's another annoyance in itself.)

When opening a session, simply report any files that can't be opened, and just don't open them. Simple, why do more? But keep track of them somewhere for later use below.

Later when saving the session, if there were any files that couldn't be opened then provide a dialog to confirm whether the user wants to retain them in the session file or remove them. Provide options to choose "Retain all missing files", "Remove all missing files", or select individually for each missing file.

---

This issue has become VERY troublesome for me, due to a peculiar usage scenario that doesn't really need to be detailed. In short, sometimes I have to access my files from one location, and sometimes via another path. I try to save separate session files for each location, and establish a naming convention to remind me. But still I often open the wrong session file. When I do N++ INSTANTLY removes all missing files from the session. (Which typically means it removes every file.) It doesn't even wait for me to close N++ or to explicitly resave the session file. The delete happens at the moment the session file is opened, for any files that can't be accessed.

[pryrt]

When re-reading my original "Desired Behavior" bullet 1, I think it becomes more clear if I phrase it as

1. When files from the active session are non-existent, they should be added to the "Recent Files History" so that Notepad++ has a record of files that used to be open but aren't any more.

I'm hoping this "bump" reminds developers that it's still an outstanding issue. I know there are a lot of open issues, and this is just one of many, but it frequently comes up in the forum, and is an annoyance to just about anyone who has to deal with session files and a network drive or USB stick or VPN. (Recent forum occurrence here)

[znik3040]

I have the same problem, unfortunately I've been created duplicate of this issue: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/13696

I don't think creating 'history' is the best resolution. Better way is creating popup window, that will list missed files with any reason (disk drive unavailable / file unavailable on existend disk drive). I think about easy method, that will give a chance to repair disk drive availability (mount network or crypted volume, subst as a drive existent directory, revert file from CVS subsystem etc), and redo for restoring session.

[Teasy]

Why not simplify it? Expected behavior:

When opening NotePad++ or loading a session:

1. Open all the previous tabs/files, and open a blank tab for unexisting files (but with correct tab name, properties etc) (Do not immediately switch to the newly opened file/tab that would probably trigger a dialog) Then after loading the session:
2. Switch to the last known active tab/file (as normal), and only then present the "this file no longer exists, keep open?" or the "this file has changed, refresh?" dialog as usual
3. Then when switching to any of the non-existing tabs/files, also present this dialog

In the code, only the initial loading/storing mechanism needs to be changed (step 1), as if the files were previously opened anyway (but with zero content). The amount of code modification for this seems very little, while the effect is significant, and can prevent people from switching to other editors xD The above "Desired Behavior" in the initial post by pryrt is overkill ! :)

(in NppIO.cpp) it looks like in the Notepad_plus::loadSession function the lastOpened var is set to BUFFER_INVALID if PathFileExists(pFn) returns false

i would add a "dummy" var that gets set to true, if the file doesn't exist so that the process of opening the file can go through (and "dummy" can be checked later for keeping the file blank/dirty/unmarked etc)

after the initial condition of path checking, the doOpen function is called but the doOpen function seems a bit confusing since it has multiple functions/purposes including opening a blank new document (MainFileManager.createEmptyFile) or even a non-existing (unsaved) document (recorded in the session file i believe)

so perhaps the doOpen would still work without any change (?) with the crucial change being just modifying the initial opening condition in the loadSession function before the doOpen function is called

and then finally, after doOpen, in the loadSession function using the last known information for each parameter of the session file/tab when available (language, etc) ignoring any unknown file/tab parameters (e.g. for position, line state, markers, etc)

note: i have not included the part of switching to the new document(s) and where any file close/refresh dialogs get triggered

[molsonkiko]

I've been poking at this problem off and on for the past couple of days, and the only thing resembling a satisfactory solution I've come up with is something like this:

if the file's path doesn't exist and it has no backup:
    create a new empty document at that path
    load the file from disk normally
    delete the new empty document that was just created
    since a file that is tied to a file on disk was just deleted:
        Notepad++ will do the usual dialog alerting the user that a session file no longer exists

I can think of at least three problems with this approach:

1. It is potentially rather slow because manipulating filesystem objects is almost always slower than working purely in-memory
2. It probably opens the door for some really bad concurrency issues where some piece of software causes files to flicker in and out of existence, such that deleting a file right after creating it could lead to permanent data loss.
3. The user gets the prompt alerting them that the file is missing immediately, rather than waiting until the user navigates to the buffer.

Naively, you might expect that an alternate approach would work, but this below approach fails:

if the file's path doesn't exist and it has no backup:
    create a "new 1" type buffer
    set the buffer's name to the name of the missing file
    set the buffer's _dirty and _loadedDirty and _unsync to true
    since Notepad++ was tricked into thinking that this "new 1" buffer is actually tracking a file on disk:
        Notepad++ will do the usual dialog alerting the user that a session file no longer exists

The problem lies with the _currentStatus attribute of buffers, which has a special value for new 1 type buffers that is different from all other buffers and ensures that Notepad++ doesn't try to tie them to a regular file on disk. This _currentStatus parameter cannot be changed programmatically, and that means that a simple in-memory approach seems impossible.

I think that adding a new field to any class will almost certainly doom a PR to failure, because Don Ho (with good reason) seems to prefer avoiding changes to classes or config files when a simple fix to a single file will do.

[molsonkiko]

@donho I've come up with a new approach to this that addresses the issues you had with my previous PR (doesn't manipulate the filesystem, only manipulates buffer objects) If you're interested, I'd appreciate the opportunity to show you my revision.

[Yaron10]

Some thoughts on the issue.

1. Session file created manually via "Save Session...". NPP should prompt the user with the File X does not exist. Create it? message. The Session file should not be modified whether the user chooses to create the file or not. Let the user handle their file.

2. session.xml created automatically by NPP on exit. NPP should prompt the user with the File X does not exist. Create it? message. session.xml should reflect and save the current session on exit. This is the essence of session.xml. (NPP just spares the user executing "Save Session..." on exit).

* File X does not exist. Create it? or any message you get on failing to open a file from the "Recently Closed Files" list.

[umop-apisdn69]

Above all, "Let the user handle their file"  YES!!At least with regard to not just summarily deleting entries from a session file merely because AT THE MOMENT they can't be accessed. Give me options how to handle it.  My complaint was this: In many of my session files I often have files on one or more mapped network shares. Sometimes those shares may be temporarily inaccessible. I may not even realize the share isn't connected until I open the session. When that happens every session file entry for the inaccessible share gets instantly deleted. Worst of all, the session file then is immediately saved. No backup. Totally beyond my control. No way to recover what may be hard to remember file locations. That's really bad behavior. -------------------Frank Sherwood  On Sep 22, 2023, at 6:35 PM, Yaron10 @.***> wrote: Some thoughts on the issue.

1. Session file created manually via "Save Session...". NPP should prompt the user with the File X does not exist. Create it? message. The Session file should not be modified whether the user chooses to create the file or not. Let the user handle their file.
2. session.xml created automatically by NPP on exit. NPP should prompt the user with the File X does not exist. Create it? message. session.xml should reflect and save the current session on exit. This is the essence of session.xml. (NPP just spares the user executing "Save Session..." on exit).

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[umop-apisdn69]

Also with regard to asking whether to create the missing file:  In my case it would not be possible to create the file. Because the reason the file can't be found is that the path location temporarily does not exist. The path is to a network path that ordinarily is mapped to a drive letter.  But for one reason or another, that mapping is not in place when I open the session. The use case of sessions referencing files on volatile network paths is the core of my issue. -------------------Frank Sherwood  On Sep 22, 2023, at 9:45 PM, Frank Sherwood @.> wrote:Above all, "Let the user handle their file"  YES!!At least with regard to not just summarily deleting entries from a session file merely because AT THE MOMENT they can't be accessed. Give me options how to handle it.  My complaint was this: In many of my session files I often have files on one or more mapped network shares. Sometimes those shares may be temporarily inaccessible. I may not even realize the share isn't connected until I open the session. When that happens every session file entry for the inaccessible share gets instantly deleted. Worst of all, the session file then is immediately saved. No backup. Totally beyond my control. No way to recover what may be hard to remember file locations. That's really bad behavior. -------------------Frank Sherwood  On Sep 22, 2023, at 6:35 PM, Yaron10 @.> wrote: Some thoughts on the issue.

1. Session file created manually via "Save Session...". NPP should prompt the user with the File X does not exist. Create it? message. The Session file should not be modified whether the user chooses to create the file or not. Let the user handle their file.
2. session.xml created automatically by NPP on exit. NPP should prompt the user with the File X does not exist. Create it? message. session.xml should reflect and save the current session on exit. This is the essence of session.xml. (NPP just spares the user executing "Save Session..." on exit).

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[Yaron10]

• File X does not exist. Create it? or any message you get on failing to open a file from the "Recently Closed Files" list.

This is what I meant. I've edited my post.

[molsonkiko]

FWIW, as the only person who is currently trying to change the code to fix this problem, I'd like to make clear that I have no intention of trying to fix anything beyond the relatively tractable problem of allowing missing files to be reloaded on restoration of a session.

People are asking for a whole bunch of other things that may or may not be resolved by my PR, but as a relatively novice contributor to the NPP code base I don't want to bite off more than I can chew. I expect that the full scope of what people are asking for is going to have to be rolled out gradually, or implemented by someone more skilled than me.

[xomx]

@Yaron10

2. session.xml created automatically by NPP on exit. NPP should prompt the user with the File X does not exist. Create it? message.

Anyone who will try to implement so must take into account that N++ could also be forcibly closed, e.g. by the Windows Update restart. Ignoring that fact will lead to the hanged app-state at the system exit (i.e. to a N++ crash with unsaved data...).

@molsonkiko IMO - this will be difficult to implement without significant changes in the N++ code logic.

My crude idea of how to realize the requested functionality:

• new checkbox, somewhere in the N++ Preferences, like "Keep inaccessible files in Notepad++ session"
• new DocFileStatus DOC_INACCESSIBLE for marking such files in N++
• when you start N++ (and provided the above mentioned checkbox is checked) ... the currently inaccessible files will be opened as (somehow visually distinguishable) empty tabs that will be non-editable (but closing of such tabs will be possible), and their previous session state in the session.xml will be preserved

• at the N++ end ... these files will be left in session.xml as is (no attempt to save or backup them etc...)

The question is what to do if such inaccessible file becomes accessible during a N++ session:

• we can detect so in the Buffer::checkFileState(), load that file and change its status to usual DOC_REGULAR (I am not for that - it could slow down the N++ substantially - network connection timeouts, etc...)
• or we can ignore it (in that case one has to restart N++ in order to could work with the files currently accessible again)

[Yaron10]

@molsonkiko,

Thank you for your work. I've expressed the correct & logical solution IMO. I respect all other opinions.

@xomx,

I meant that NPP should prompt the user on startup. There are other possible messages on startup. For example: if stylers.model.xml & stylers.xml are missing.

Putting aside the Windows Update issue.

1. Why should there be a difference between our case and failing to open a file from the "Recently Closed Files" list? - In both cases the user is requesting NPP to open a file, and that request can not be accomplished.

2. We must take into account a case where the user has deliberately deleted some file(s) included in session.xml. - In that case, opening "empty tabs" without asking the user would be wrong.

3. Why complicate the solution even more with a new setting, DOC_INACCESSIBLE etc.?

[xomx]

@Yaron10

I meant that NPP should prompt the user on startup. There are other possible messages on startup. For example: if stylers.model.xml & stylers.xml are missing.

On startup it is ok. But I had impression that you like "NPP should prompt the user with the File X does not exist. Create it? message." even at the N++ exit in your No. 2.

1. Why should there be a difference between our case and failing to open a file from the "Recently Closed Files" list? - In both cases the user is requesting NPP to open a file, and that request can not be accomplished.

Where I said so?

• We must take into account a case where the user has deliberately deleted some file(s) included in session.xml.

  • In that case, opening "empty tabs" without asking the user would be wrong.

• Why complicate the solution even more with a new setting, DOC_INACCESSIBLE etc.?

Fair enough (I stated "crude" idea).

So I will complicate it even more ;-) - I will modify the approach to cover also the 'lazy loading' of files in N++.

I also saw people here having a different problem - they are opening too many (or too big) files in N++ or their file(s) can be on a drive, which needs a time to 'wake up' from a sleeping state. Examples (I intentionally omit "#") : 14000, 12019, 11741. But they all have wanted to start working in N++ (almost) immediately. Which is reasonable, as nobody usually wants to edit all the opened files at once. So I will adjust my previous proposal a little:

• add one more new DocFileStatus DOC_DELAYLOADED
• at the N++ start ... load really only the file of the current session active tab (other file-tabs will be created but with the status DOC_DELAYLOADED)
• then when an user switches to one of the currently delayloaded-tabs in N++ ... either the file can be loaded as usual (so status will change to usual DOC_REGULAR) or it can obtain the previously mentioned DOC_INACCESSIBLE status (in case of the inaccessibility of such file and when that new option will be checked in the Preferences, otherwise there will be a dialog 'Missing file - keep that or not?')

Similar logic can certainly be applied to the aforementioned "Recently Closed Files" list etc.

[Yaron10]

@xomx,

Binding "Lazy Loading" with the current issue is clever & visionary on the one hand, and indeed complicates it even further OTOH. :)

If and when "Lazy Loading" is implemented: shouldn't NPP even check if the file can be loaded? On using "Open All Recent Files", I wouldn't like to see a tab pointing to a path that (possibly) never existed on the current machine.

Back to our case: what if the Session file contains only one missing file?

[xomx]

@Yaron10

, and indeed complicates it even further OTOH. :)

And this is the reason that I will not continue further here (e.g. by creating a pseudo- or POC-code for N++) until Don at least preliminary agrees on something like that. I see that he has already assigned himself to this issue, so maybe he already knows a better solution for all of this. After all, he knows the N++ code and its possibilities best.

If and when "Lazy Loading" is implemented: shouldn't NPP even check if the file can be loaded?

As I said above - when in a LazyLoadingMode, the N++ should only care for the currently opened/activated file/tab. So when e.g. directly manually opening a file via menu File > Open, it should always check for the file existence and acts accordingly.

On using "Open All Recent Files", I wouldn't like to see a tab pointing to a path that (possibly) never existed on the current machine.

If you do so and the proposed new Preference option "Keep inaccessible files in Notepad++ session" will be OFF, but a LazyLoadingMode will be ON, you should obtain your desired behavior indeed (no tabs pointing to non-existing files).

[Yaron10]

@xomx,

And this is the reason that I will not continue further here...

👍

[donho]

If the files were truly permanently gone (deleted intentionally), that behavior makes sense.

But if the reason the files are gone is because of a temporary problem outside of their control, then the users get confused when those files don't come back into Notepad++ when the temporary problem is resolved. Examples include:

@pryrt

How about the following behavour: While opening a session, all the absent files are ignored silently (as current behaviour is), but they are memories for the next session.

Here is the example: 5 files A, B, C, D and E are opened in Notepad++, A, C & D are in **C:**, B & E are stored in a USB key. User closes Notepad++ and A, B, C, D and E are saved in the session, then the user removes the USB. The following day the user reopens Notepad++ without insert USB - only A, C & D are opened. He/she then realized that the USB is not insert. User inserts USB, closes Notepad++ and relaunches it. Now A, C, D, B & E are opened in Notepad++ with the order given.

Do you think such behaviour is reasonable and expected?

Notepad++ checks "Keep missing files in the saved session" setting:

I would say, the option is not necessary, since the scenario described above is retro-compatible with the behaviour we have currently in master.

[alankilborn]

@donho said:

How about the following behavour: While opening a session, all the absent files are ignored silently (as current behaviour is), but they are memories for the next session.

This only works for ONE restart cycle?

Say user has 37 files on C: open into file tabs in N++, and 2 files on USB drive. User restarts without USB and may not notice 2 missing files among 37 other tabs. User goes ahead with his work on C: drive files and never needs the USB file tabs during this cycle, thus perhaps user doesn't notice that the tabs aren't there. User quits. User comes back the next day and inserts USB drive because he needs to work on those files now, only to find his 2 tabs for USB files have gone missing...

[molsonkiko]

FWIW I have mixed feelings about silently remembering missing files, mostly because you have two choices if you do that:

1. Forget missing files eventually according to arbitrary (and possibly confusing) rules
2. Remember missing files silently forever until the session.xml gets bloated and users get frustrated

I understand the motivation for silent remembering, but don't forget this issue.

On Fri, Sep 29, 2023, 12:58 PM alankilborn @.***> wrote:

@donho https://github.com/donho said:

How about the following behavour: While opening a session, all the absent files are ignored silently (as current behaviour is), but they are memories for the next session.

This only works for ONE restart cycle?

Say user has 37 files on C: open into file tabs in N++, and 2 files on USB drive. User restarts without USB and may not notice 2 missing files among 37 other tabs. User goes ahead with his work on C: drive files and never needs the USB file tabs during this cycle, thus perhaps user doesn't notice that the tabs aren't there. User quits. User comes back the next day and inserts USB drive because he needs to work on those files now, only to find his 2 tabs for USB files have gone missing...

— Reply to this email directly, view it on GitHub https://github.com/notepad-plus-plus/notepad-plus-plus/issues/12079#issuecomment-1741412638, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALAQAI4SVR65DCTB7OTK253X44R4RANCNFSM6AAAAAAQCMW3Y4 . You are receiving this because you were mentioned.Message ID: @.***>

[pryrt]

Now A, C, D, B & E are opened in Notepad++ with the order given.

Do you think such behaviour is reasonable and expected?

In terms of user expectations, yes. Though I can see the potential for bloat.

Maybe store a lastSeen date as an attribute, and if it's been more than X days, prompt the user asking if they want it to remain in session. (Or a count of "times missing", and if it exceeds threshold, then ask.)

[donho]

@alankilborn

This only works for ONE restart cycle?

If your question is: "Will these failed loaded files be always remembered through the several sessions until the success of its loading (the path matched)?" Then the answer is yes.

@molsonkiko

FWIW I have mixed feelings about silently remembering missing files, mostly because you have two choices if you do that:

1. Forget missing files eventually according to arbitrary (and possibly confusing) rules

The rule may not be explicit, but not confusing at all.

2. Remember missing files silently forever until the session.xml gets bloated and users get frustrated

If you mean the loading time of session.xml, it could be time consuming indeed, but when the amount is really huge.

@pryrt

Maybe store a lastSeen date as an attribute, and if it's been more than X days, prompt the user asking if they want it to remain in session. (Or a count of "times missing", and if it exceeds threshold, then ask.)

I'm not for such solution. If the consequence of adding an enhancement is making the code more complex, UX more frustrating and behaviour less straightforward, then we should ask ourselves if it's really an enhancement.

[ArkadiuszMichalski]

@pryrt

Maybe store a lastSeen date as an attribute, and if it's been more than X days, prompt the user asking if they want it to remain in session. (Or a count of "times missing", and if it exceeds threshold, then ask.)

But again, the fixed value may not suit everyone (too early or late). Generally, doing something automatically without being able to control it is adding another problem to the current one.

@donho

I'm not for such solution. If the consequence of adding an enhancement is making the code more complex, UX more frustrating and behaviour less straightforward, then we should ask ourselves if it's really an enhancement.

For me personally, automatic cleaning of the session file from inaccessible files (let's assume for a while) is extremely burdensome. I have many working sessions (each of them has a lot of files) and sometimes some are unavailable (for various reasons) and very often I lose my fixed working environment. What saves me here is a backup of session files, but it's a pain. In this case, I believe that the additional code compensates for these inconveniences.

Analyzing the proposed solutions, I must admit that I do not have a clear opinion on this matter. Changing the current behavior will certainly bother someone and without a additional switch in option, new reports will probably appear. Silently remembering inaccessible files is probably the easiest, but cleaning them up may be a problem (if a lot of them accumulate and they are no longer needed). Maybe an additional command for a session cleanup would be a solution? Thanks to this, they could be performed on demand (when necessary).

The xomx proposal with empty tabs is also interesting (because if necessary we can only close some individual inactive files) and generally we can see the state of the entire session (including dead entries). But if it's too complicated/too much, doing it without empty tabs will also be satisfactory.

I don't have much time at the moment and I don't know when it will change, but I will try to come here and look at each proposal and express my opinion. In the meantime, I recommend the Explorer extension (from funap) where in some sense this problem has been reduced (issue 27, issue 20).

[donho]

@Yaron10

https://github.com/notepad-plus-plus/notepad-plus-plus/issues/12079#issuecomment-1732127183

1. Session file created manually via "Save Session...". NPP should prompt the user with the File X does not exist. Create it? message. The Session file should not be modified whether the user chooses to create the file or not. Let the user handle their file.

2. session.xml created automatically by NPP on exit. NPP should prompt the user with the File X does not exist. Create it? message.

Finally for you Session file created manually via "Save Session..." & session.xml should have the same behaviour, do you confirm?

If user chooses No for not Create the files, what should happen later (for the next session)?

[donho]

@ArkadiuszMichalski Thank you for your pertinent opinions.

The https://github.com/notepad-plus-plus/notepad-plus-plus/issues/12079#issuecomment-1732427166 with empty tabs is also interesting (because if necessary we can only close some individual inactive files) and generally we can see the state of the entire session (including dead entries). But if it's too complicated/too much, doing it without empty tabs will also be satisfactory.

The PR done by @molsonkiko is close to what has suggested by @xomx - has anyone tried this PR? Besides the fact that code is simple (a little bit tricky though), the interesting part of the PR is, after asking user if he/she wants to keep the each absent file in the editor, and loading session being done, user can insert the USB (tested only with USB), and reload the file directly. Furthermore, while switching into other place holders (empty files), a question of reloading current file is asked.

Surly, this solution needs more work: an option to activated this session enhancement and some refinement (make file absent status more visually & suppressing some redundant dialogs).

What do you guys think about this PR as the solution of this issue?

[xomx]

@donho

The PR done by @molsonkiko is close to what has suggested by @xomx - has anyone tried this PR?

I tried. But when I was at this place in his STR:

"TO TEST THIS PR:

Open a file (let's call it file A.txt) in one edit view. Add some text and save it.
Open a file (call it file B.txt) in the second edit view. Add some text and save it. The purpose of this is to verify that the PR works in both edit views, not just the main one.
Close Notepad++.
Delete or rename both file A.txt and file B.txt
Reopen Notepad++. You should get prompts asking you if you want to keep file A.txt and file B.txt, since those files no longer exist on disk.
Close the session again ..."

I got this at the N++ exit (with 'Enable session snapshot and periodic backup' checked):

Or with the previously mentioned Preferences option unchecked:

I do not want to save any new file at this point with the same name as the currently inaccessible one. It can be confusing - I could start to use the new placeholders instead of my original files and then my original files could come back to life again and ... real mess.

I even do not like to be bothered at this point with any messages. I just need to keep my N++ session intact, with possibly some of the session files/tabs in that "DOC_INACCESSIBLE" read-only-empty-tab-state (only when a new Preferences option for such new behavior will be ON, of course).