@gwiora:
What maybe might be at play here is that behind your back, Windows may use another temp directory inside the temp directory.
That is, I often find that the environment variables %TMP% and %TEMP% point to e.g., C:\Windows\Temp but in reality C:\Windows\Temp\1\  or C:\Windows\Temp\2\ are being used.

However, xlswrite.m and helper functions invoke Octave's function 'tempname' which in turn invokes regular Windows functions, so AFAICS xlswrite.m etc. should just work "as advertised".

This bug report is some 6 months old now with status "Need info". I'll set status to "Works for me" and I'll leave it open for at most another month, or until you've reacted here (whichever comes first).

Thanks

The error seen in the 3rd verbatim block of comment #1 seems to be due to an issue with the 'make_absolute_filename' function. That is conspicuous in the first lines there but I overlooked it:

>> cd c:
>> xlswrite ("z:subst2.xlsx", {"Col1", "Col2"; 5, 6; 7, 8}, "", "", "oct")
xlsclose: could not zip files in C:\Users\philip\AppData\Local\Temp\oct-IOmPy1 to c:\\z:subst2.xlsx
:

Setting a breakpoint in xlsclose.m at L.139
( xls = _OCT_spsh_close_ (xls, "xlsclose", force); )
and doing this:

debug> xls
xls =
  scalar structure containing the fields:
    xtype = OCT
    app = xlsx
    filename = Z:bug64363B.xlsx
:

debug> make_absolute_filename (xls.filename)
ans = c:\Z:bug64363B.xlsx

shows that make_absolute_filename cannot process / is oblivious to the working directory on another drive.
ISTR this issue has been reported, or at least noted, several years ago in the course of other issues pertaining to 'make_absolute_filename' and/or 'canonicalize_file_name' functions and how these work on Windows. But maybe here it's due to the subst command.

However this is not the bug the OP posted.
I'll check if I can reproduce that some other way.

@gwiora:
Maybe it isn't 'movefile' but rather the zip function that's at fault, but I doubt that.

What you can do is enter a 'breakpoint' statement in the file private/__OCT_spsh_close__.m (in the io package subdirectory) just above the lines where the zip is created (that way search path issues are avoided for private functions) and try the xlswrite command. It'll stop at the 'breakpoint' statement. From then on 'dbstep' through the file (just use the buttons in the GUI editor) and inspect if files are created properly. Or better:
Hint: I usually select (highlight) a statement and press <F9> to execute it manually, one by one. That way you can avoid being thrown out of debug mode when an error is hit, and you can also find out exactly which statement provokes the error (which is otherwise masked because of the try-catch block around it all).
If it indeed is the 'movefile' function, you can try to mimic the command in a cmd32 window outside Octave. Maybe the underlying 'move' command in Windows itself is the culprit.

Anyway this is how I would start tackling this issue. Hopefully it helps you to debug this further.

BTW I think the SUBST command might merely be some wrapper for the 'net share' or 'net use' command. Whatever, the resulting drive mapping is the same.

Hmmm, I often save spreadsheet files to some other drive, network or not, and had not met your issue yet.

"drive Z is linked to a network drive mapping a folder on my drive C"
what do you mean exactly? Did you do something along the lines of the "SUBST" command?
What are the commands you used to map your folder on C: into a network drive letter Z: ?

I tried the following:
In a cmd32 window:

C:\>subst z: c:\users\philip\mydocs\octave

C:\>dir z:
 Volume in drive Z has no label.
 Volume Serial Number is 1E0D-1C75

 Directory of Z:\

09-Mar-23  09:59    <DIR>          .
09-Mar-23  09:59    <DIR>          ..
07-Dec-19  21:46            15 446 3D-clip.pdf
07-Dec-19  21:45            21 562 3D-clip.pptx
27-Aug-22  23:10    <DIR>          a
20-Mar-12  23:11         1 261 949 a.csv
15-Feb-15  18:31            14 336 a.xls
02-Apr-13  23:03             1 075 aa.ods
:

and drive Z: neatly shows up in 'My Computer' as a mapped network drive.

Next, in Octave 9.0.0 (dev):

>> cd c:\
>> getenv ("TEMP")
ans = C:\Users\philip\AppData\Local\Temp
>> getenv ("TMP")
ans = C:\Users\philip\AppData\Local\Temp
>> cd z:
>> xlswrite ("subst.xlsx", {"Col1", "Col2"; 1, 2; 3, 4}, "", "", "oct")
ans = 1
>> ls -l subst.xlsx
-rw-r--r-- 1 philip None 7265 Jun 28 22:02 subst.xlsx
>> pwd
ans = z:\
>>

so I cannot reproduce your issue using a "SUBST"ed network drive that way, with Z: as current drive.

However:

>> cd c:
>> xlswrite ("z:subst2.xlsx", {"Col1", "Col2"; 5, 6; 7, 8}, "", "", "oct")
xlsclose: could not zip files in C:\Users\philip\AppData\Local\Temp\oct-IOmPy1 to c:\\z:sub
st2.xlsx
warning: xlsclose: Moving file "C:\Users\philip\AppData\Local\Temp\oct-IOmPy1\z:subst2.zip"
 to "c:\\z:subst2.xlsx" failed with message: "no files to move"
warning: called from
    __OCT_spsh_close__ at line 76 column 9
    xlsclose at line 139 column 13
    xlswrite at line 242 column 11

warning: xlsclose: file z:subst2.xlsx could not be saved.
Read-only? unsupported file format? in use elsewhere?
(File pointer preserved.
 Try saving again later, or with different file name, or as different file type.)
error: warning: STATE structure must have fields 'identifier' and 'state'
error: called from
    __OCT_spsh_close__ at line 77 column 9
    xlsclose at line 139 column 13
    xlswrite at line 242 column 11

so writing a spreadsheet file on a network drive that isn't the current drive doesn't work well.

AFAICS this isn't a bug in xlswrite.m (or rather, the private function __OCT_spsh_close__.m that does the write-to-disk) but rather due to the way Octave's movefile function handles TEMP files with network drives.
There are already a few kludges in __OCT_spsh_close__.m that are meant to help successfully move the .xlsx file created in %TEMP% to the network drive in question, and IIRC all these kludges were needed especially for Windows systems.
While writing this comment I got reminiscences of various 'movefile' issues when I wrote and later on repeatedly patched the OCT interface spreadsheet I/O; there must be old bug reports about it.

I'm inclined to adapt this bug report's title to reflect that it is Octave's 'movefile' function that may be the problem but that has to be confirmed first.

As to "regression", I'm unsure. It may well be that you're just the unlucky first person to hit this. First we have to see if this bug also happens with older io package and Octave releases.
Adapting "Item Group" to mere "Unexpected error".

ATM I don't have time to dive further into this; mid-July I hope to be able to investigate. Hopefully in the mean time other developers / contributors can help finding out what goes wrong with the movefile function and/or how it is used in __OCT_spsh_close__.m .