[Top][All Lists]

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

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

From: Markus Mützel
Subject: [Octave-bug-tracker] [bug #51203] xlswrite(...'com') output results in a corrupted .xlsx / unicode issues
Date: Tue, 4 Jul 2017 04:48:05 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0

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:


  Message sent via/by Savannah

reply via email to

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