Yes, I don't do it often, but I think you'd update to the stable branch and use 'hg graft -r 9fa577cf9f4e' to copy it over.

Thank you, fixed for me now.

Bug #55823 is a similar bug, seemingly also triggered by 'rmdir' closing files in the editor, even if they are saved, but only manifests on Windows.

You probably already found this, but it looks to me like the logic in the 'file_editor::handle_dir_remove' function is incorrectly deciding that the open tab lives under the directory that was rmdir'd. Maybe on Windows this also needs to account for backslash directory separators?

Definitely one of my patches for closing tabs related to files removed from within octave introduced this issue. I will have a closer look into this.

Oopsie, that should read "bug #55823, comment #22".

This bug happens because the 'file_editor_tab::file_has_changed' slot is being called even when the editor tab does not have a file name. The '_file_name' member variable is an empty string, 'file_exists' is false, and '_edit_area->isModified ()' returns true.

There's a lot going on in that slot, but is the purpose of that function only to handle the case when a file on disk is modified outside of the Octave editor? If so, then should that slot simply return immediately if '_file_name' is empty and just leave things alone? Or will that break some other case, like exiting Octave or closing the tab?

Cc'ing Torsten.