This particular bug keeps me from using Octave 5.1.0. I understand that there is a bug fix, but I do not know how to make use of that. I have no experience in making my own build.

Is there any beta build or so in which this bug fix has been applied?

With the patch I can't reproduce the original error anymore, so it looks to be fixed. I have no time/priority this week for more testing.

BTW in comment #45:
It is xlsclose.m not xlsopen.m that calls a private function that in turn removes the temporary directory.
I could only partly follow the reasoning in comment #46 but that's probably moot.

Thanks Torsten!

Thanks Torsten.
This week I'm in a course so I have to squeeze testing somewhere in between the scenes.

Is this fix also meant for stable? (can't see that right now). If it works (I suppose it does) the fix might need to go there as well, as it can be viewed as a sort of regression.

Thanks for the tips for speeding up the mxe cycles.

xlsopen removes a temporary directory and this might be the cause for the editor closing the tabs. I guess that in windows, the test whether the open files are located in the removed directory fails, maybe due to the drive letter concept. More tests will follow.

@Georg Wiora, comment #41:
As outlined vaguely in (top of) comment #7, all that is needed are the spreadsheet-open and spreadsheet-close user-accessible functions xlsopen.m and xlsclose.m. Both are called by xlsread.m, xlswrite.m and xlsfinfo.m.
in fact I think even just the private funcs __OCT_spsh_open__.m and __OCT_spsh_close__.m will do the job.

@Torsten, comment #39:
I still suspect that something with unpack or unzip or so is involved or at least interfering.
In case of installing the io package (or any other package) the .tar.gz file needs to be unpacked first; afterwards the temporary unpacked archive is wiped with the same 'rmdir (<unpacked archive>, "s")' command that looks involved here.

For debugging there's a trick that I tried some time ago with a "keep-files" (IIRC) configure option that will allow to patch Octave in the tmp-default-octave folder in mxe and then continue or restart the build with make zipdist etc.
In fact I often just let it build and install in the ./dist/octave..../ folder, skip building the archive, and ran it from there by rebooting in Windows (or starting a Windows VM) and accessing the ./dist/octave.../ hierarchy from the Windows side using shared folders or ext2fsd.
Some details are in the wiki.

> @Torsten, can you confirm that the bug is only exposed after first running xlsread() (using OCT interface, i.e., w/o Java and/or Excel)?

@Philip: You do not need to call xlsread. It is sufficient to call xlswrite with OCT interface. The bug does not appear using COM interface.

I can confirm the issue on Window 7 following the steps of comment #36.

Remarkably, the tabs are closed before rmdir () prompts whether to close the entire directory or not.

And even more remarkably, the editor tabs were also closed at the end of the io package installation!

I can confirm the behavior described by Philip. I have a script using xlsread and xlswrite that shows the same effect. After running the program GUI complains that the file in the editor would have been deleted and closes the tab.

I am using octave 5.1.0 on Windows 7.

Yes, for me it doesn't reliably show the bug either.

But intriguingly for me the bug is reliably reproduced if I add the lines:

fn = 'C:\Users\<your login name>\AppData\Local\Temp\testdir'
try2_rmdir (fn)

to the readtest.m script that the OP supplied in comment #2 and select & execute (F9) them from there.

Maybe something with the file's encoding? just a WAG.

Yes, zoom level is per-tab that's why I was asking for other open tabs.

I agree that the cause is most probably in the fix for bug #43922, but I do not think that the path separator is the cause. From the Qt documentation:

Qt uses "/" as a universal directory separator in the same way that "/" is used as a path separator in URLs. If you always use "/" as a directory separator, Qt will translate your paths to conform to the underlying operating system.

Unfortunately, I am currently facing problems with my mxe environment and am not able ti build octave for my windows vm.

@Philip: Which tabs are changing the font size? Are there other tabs open while the considered tab is closed?

Just define the following command-line function:

>> function try2_rmdir (fn)
  confirm_recursive_rmdir (0, "local");
  rmdir (fn, "s");
endfunction
>> which try2_rmdir
'try2_rmdir' is a command-line function
>> try2_rmdir (fn)

Then, create some test directory structure (can be empty) in %APPDATA%\Local\Temp  (in my case C:\Users\Philip\Appdata\Local\Temp), call it e.g., 'testdir'

In the GUI editor create some m-script file containing:

## substitute your login name
fn = 'C:\Users\<your login name>\AppData\Local\Temp\testdir'
try2_rmdir (fn)

and save it to disk.
Select both lines, and press F9
==> editor tab is closed.

OR,

open the m-script file in an editor tab, and call the script from the command line
==> same effect, tab is closed.

What I learn from this is that the io package is off the hook (which I suspected anyway, the io package code has worked fine until early August last year and works fine in Linux as well)
==> Adapting title
(Hopefully the new title describes the situation more clearly)

Ok, thanks to both of you for the additional details. I can't reproduce this bug at all on Debian, and I don't have access to Windows to test it on. It's possible this is also related to the same change that caused bug #55888, but only manifests on Windows for some reason.

Yes, on my Mageia 6 system I couldn't reproduce it either, that's why this bug is still for Windows only. I didn't try your code in comment #13 on Linux yet.

Torsten wrote last summer in one of the comments in bug #43922 s/th about specific Windows issues. Now, reading back on it I remember that there wer several seemingly loosely correlated bugs that all related to bug #43922.
So I'm not surprised that some manifestations of what we see here only apply to Windows and some apply to "Any" OS.

Let's just wait for Torsten's fix in bug #55888 and see if it solves all issues here.

Mike, our posts crossed.

See my comment #4 for an example of an unsaved (modified) tab exactly using Joel's example files.

BTW that the OCT interface is required is because that unzips and zips back the spreadsheet files and then wipes the unzipped archive using code somewhere in the io scripts.
The COM interface doesn't do that.

@philip When I read the original bug here, I don't see anything about an unsaved tab in the editor. Joel gave a script file 'readtest.m' and said that running it in the editor triggered this bug. He said that the file was closed in the editor and then he reopened it, implying that the file was indeed already saved.

Are you saying that you are unable to reproduce this bug with the files that Joel provided in comment #2? If so then this bug needs more information from Joel about precisely how to reproduce this. If it can't be reproduced except by pasting into a new unsaved tab, then this should be closed and bug #55888 will continue.

I asked Joel in comment #15 for more details, for example how exactly was the script run in the editor, was it saved or unsaved, was it run with F5 or F9, etc.

With the code example in comment #13, if you click "Save" and save the file the bug is  "neutralized".
But running only the first two statements, copying the 3rd line to a new blank script, selecting it and pressing F9 again triggers the bug.

I think bug #55888 is simply a dupe.

I have tried a couple of other machines with older releases of Octave installed: Xubuntu running Octave 4.2.2 and Windows 7 running Octave 4.4.1. All machines have the latest io package from forge: 2.4.12.

Neither this bug nor 55888 occur in either environment, so it's probably something new/changed in the Octave main codebase since 4.4.1 release in August that is causing these problems in 5.1.0.

I should have tested that earlier.

Joel - OK, it sounds like this bug is still about something very specific to the io package, that a script that has been saved and not modified is closed in the editor. If that's what you're seeing, I think we need more information about how to reproduce that. Can you verify that readtest.m is saved on disk, no changes have been made to it, and you run it with what, F5 or F9? And then the file is closed in the editor with no prompt shown?

I personally don't have Windows to test with, but I downloaded all the attachments you provided in comment #2 and I don't see any problems on my Debian system, the script stays open in the editor after multiple tries to run it with either F5 or F9.

I will file a separate bug report about the script closing an unsaved file when rmdir is called, that is very easy to reproduce.

Thanks, here's a far simpler example that I tried in Octave 5.1 and on the development branch.

dn = tempname ();
mkdir (dn);
rmdir (dn);

Start Octave, open a new tab in the editor, paste the above, don't save it, highlight all text, and press F9 for "Run Selection". Octave will prompt for the file in the editor to be either closed or saved. If I choose "Save" and give it a file name, the file stays open in the editor. This is on Debian.

Does this match what you're seeing on Windows?

That doesn't seem to describe what this bug report was originally about. If the script is saved first as "readtest.m" then I don't see any prompt and the file is not closed.

Also, cd'ing hence and forth shouldn't interfere with a script or file in the editor. That also happens with a file in the editor and then running _run_test-suite_ - I saw no problems with that.

@philip Can you give an example for reproducing without the io package? What is the relation between xls.workbook and readtest.m? There's a lot of code there, but it looks to me like there is a cd to that directory, then a cd back, followed by the rmdir? Maybe the changing of working directory is what's causing the response in the editor?

Even weirder:

If:
(1) I add the following lines into readtest.m without saving the file:
xls = xlsopen (''test.xlsx', 0, 'oct');
xls = xlsclose (xls)

(2) I open xlsclose.m in the editor ('edit xlsclose')

(3) Add a breakpoint at xlsclose L. 121

(4) Back in readtest.m, I select the two newly added lines and press F9 to execute them

(5) When execution stops at L.2121 in xlsclose.m, I click the "Step into "button
==> execution continues in _oct_spsh_close_.m

(6) Step all the way through _oct_spsh_close_.m

(7) And when _oct_spsh_close_.m is finished, I step all the way through xlsclose.m until back in the prompt in the octave terminal,

==> the file readtest.m is still in the editor but I cannot edit it anymore, it is blocked.
Only thing I can do is click the close button and in the pop-up menu do "Save", "Discard" or "Cancel".

Trying again, and adding some character to readtest.m after every debug step in _oct_spsh_close_.m, it turns out it is line 99 in _oct_spsh_close_.m:

rmdir (xls.workbook, "s");

that does it. when I step over it, the editor screen flashes.
When back in readtest.m I press the close button, if clicking "cancel" the file becomes editable again.

I'm cc-íng the GUI guru; a while ago some fixes were made to the GUI editor that smell to be related.

... and I can reproduce it on Windows 7 as well.

Joel, sorry didn't have time yet and a sore back got in the way. That inconvenience is over but I have a busy time anyway.

Weird.
I only rarely use Win10 (rather Win7, until Jan next year when I have to switch) but I'll try to have a look.
To that end I do need more info:

- Which "interface" do you use? Do you have MS-Office installed?

- Please attach (do not post or include in "verbatim" tags) the output of:

diary on
[a, b, c] = chk_spreadsheet_support ("", 3)
diary off

and upload the "diary" file to this bug report.
If you have a very simple Excel file that "works" to reproduce this behavior please upload it as well.