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

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

[Octave-bug-tracker] [bug #51203] xlswrite(...'com') output results in a


From: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #51203] xlswrite(...'com') output results in a corrupted .xlsx / unicode issues
Date: Tue, 20 Jun 2017 14:36:04 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46

Follow-up Comment #45, bug #51203 (project octave):

Andrey,

The bug you are referring to now (apparently unreliable writing to file) has
been reported before (can't find it now, was about 3-4 months back IIRC). It
has to do with very fast hard disks. I hit this already 3-4 years ago.

Mike Miller and John Eaton figured it would be a bug in hardware drivers, but
now I think it is really a bug in zip (that zips the various XML files
together, .xlsx is a mere zip archive):
 
* zip hands over the actual writing of the zip file to disk to lower level
routines and returns.
* The lower level routines may take their time to do the actual writing.
* Next however, as zip has returned, unzip is invoked and it tries to read the
.xlsx file that hasn't been finished yet.

I think zip should return only after having verified that its output file has
been finished completely.

In the io_xls_testcript.m and io_ods_testscript.m function files in the io
package you can see that I've entered various pause commands to separate
xlswrite and xlsread (odswrite and odsread) calls. Those delays are there for
the very same reason you complain about.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?51203>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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