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: Sat, 15 Jul 2017 07:43:49 -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 #67, bug #51203 (project octave):

.ods and .xlsx are zipped archives containing 2 or more trees of subdirs, all
(including the "root" dir) containing XML files.

xlswrite (or rather some private functions that are called in a chain of other
functions) unzips such an archive to a temporary subdirectory, modifies it,
and in the end zips it back into the original place, overwriting the original
.xlsx/.ods file.
After processing the temporary subdir with the unzipped archive is wiped.

xlsread and xlsfinfo (or rather private functions .....) merely do the same
but don't modify it and in the end just wipe the temporary subdir.

The hairy issue here is that this bug is very hard to reproduce; sometimes it
pops up, most of the time it doesn't. It makes one think of OS issues behind
the scenes (like temporary swapping to disk of, or briefly blocking access to,
required system libraries).
At one time I figured that maybe the original archive was somehow locked by
zip/unzip, and releasing the lock might be delayed, but AFAIU that isn't the
case.
But the thing that I suspect the most on at least Windows is virus/malware
scanners. These are explicitly blocking all access to new files until those
files can be declared "safe".  (Which doesn't explain why I saw this bug
mostly on fast HDDs/SSDs.)

In the io package's spreadsheet test functions there are pause(0.25)
statements after each call to xlswrite (or odswrite) to avoid any occurrence
of this bug.
On my two dev boxes I just tried with all delays set to 0 (i.e., pause(0), or
no delay) and I couldn't reproduce this bug at all anymore. Next week I can
try on my PC at work where I hit this bug more often.


    _______________________________________________________

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]