[Octave-bug-tracker] [bug #51203] xlswrite(...'com') output results in a corrupted .xlsx / unicode issues

[Markus Mützel]

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

Thanks to a lot of trial and error with Andrey's help, we could pin the second
issue down to some strange behavior of InfoZip:
InfoZip relies on the current working directory (cwd) to function properly. On
some systems (like on Andrey's and others), it looks like it takes some time
to update the cwd properly. That does not seem to be handled by Octave's
"unpack" function.
When calling InfoZip directly and taking special care that the cwd has changed
properly, the behavior that Andrey observed disappears on his system.
The attached patch includes these changes.

Btw, we quickly checked with using 7-Zip (because we both had it at hand).
That program accepts absolute paths for source and destination (unlike InfoZip
that relies on the cwd for relative paths in the archive). Using 7-Zip, that
issue disappeared as well (without any additional hassle).
I am still not sure why on some systems the issue with the slow cwd change
exists in the first place. But we might consider using a more modern program
than InfoZip (which dates back to 2008 for the zip part and 2009 for the unzip
part) that better handles those systems.

PS: The patch for the other issue (transcode to UTF-8 from any supported code
page) is in comment #25 of this already quite long discussion.

(file #41114)
    _______________________________________________________

Additional Item Attachment:

File name: bug51203_xlsx_InfoZip.patch    Size:7 KB


    _______________________________________________________

Reply to this item at:

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

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