octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #64363] [octave forge] (io) xlswrite to existi


From: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #64363] [octave forge] (io) xlswrite to existing file fails if temp dir is on different drive
Date: Wed, 28 Jun 2023 16:52:51 -0400 (EDT)

Update of bug #64363 (project octave):

              Item Group:              Regression => Unexpected Error or
Warning
                  Status:                    None => Confirmed              

    _______________________________________________________

Follow-up Comment #1:

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 .



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64363>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]