bugGNU Octave - Bugs: bug #42779, [OF] odswrite: "zip I/O...


bug #42779: [OF] odswrite: "zip I/O error" when in different directory

Submitted by:  None
Submitted on:  Tue 15 Jul 2014 10:47:54 PM UTC  
Category:  Octave Forge Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Wont Fix Assigned to:  Philip Nienhuis <philipnienhuis>
Originator Name:  p8rpp Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  other
Operating System:  Any

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Thu 14 Aug 2014 06:55:34 PM UTC, comment #8:

With "looking closer" I mean that while I first assumed it obviously would be a bug in the io pkg, I couldn't find any wrong behavior on Linux and Windows (tmp and also my home dir) so I went back to your post and paid more attention to the actual error message. Only then it finally trickled down here that it was the zip command that threw errors, not Octave.
So I experimented with zip; results are shown in my previous post. I find the results pretty convincing.
The bug report could also have been closed with "Works for me".

Now it may be that zip emits a "cannot find file/subdir" error if it tries to write to a read-only location; but then again that deceiving error message is a zip bug, not an Octave-io package bug.
If you want to experiment yourself:
the command to execute is
"zip -q -r </full/path/to/new/zip/file> . ."
(w/o quotes)

Now it's not as if I am 100 % sure. On my PC at work, a very fast dual-Xeon beast, I often get zip-related errors that I suspect are due to trailing file I/O - i.e., zip actions not yet finished when unzip already tries to access the not-yet-completely written zip file. I have no other explanation.

BTW I've just uploaded io-2.2.3 to the package release tracker. Should be up in a few days. In io-2.2.3 I did fix the return value for xlswrite/odswrite when they encounter file close errors.

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Wed 13 Aug 2014 07:18:18 PM UTC, comment #7:

Sorry for a late reply to your question, which was
"Looking closer at your bug report, do you mean you want to create a new .ods file in a not-yet-existing subdirectory? I.e., do you want that new subdir to be created on-the-fly automatically when writing to a new .ods file? "

I am trying to write to an existing .ods file in an existing subdirectory different from octave's current work directory.

So the file and its subdirectory do already exist.

Now I tried the same procedure in two different folders on /tmp, and there was success. Then i tried the same in yet two other different folders within the homedir tree, and there was the error message again.

Do you think there might be permission problems? I looked into this briefly, but couldn't find something. Which user is evoking zip to write to the file?

Thanks for your patience,

Peter P. <p8rpp>
Wed 13 Aug 2014 06:43:26 PM UTC, comment #6:

Answering my own question:

which gives the exact same error as the OP gets. On Windows (mingw/msys) zip gives the same error messages.

So this is due to zip not being able to create intermediate directories. That is something that can't be fixed on the Octave side unless a lot of effort is spent in parsing filenames, checking presence of each subdir in the filename and creating them if required. I do not think that is worth the trouble.

Closing with "Won't fix".
(I will fix the other bug, i.e., proper return value)

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Mon 11 Aug 2014 02:54:51 PM UTC, comment #5:

@ OP:
I've found & fixed a related bug where ods2oct (actually, its private helper routine) wouldn't create new files with OCT interface. But no zip errors, neither on Windows nor on Linux.

Looking closer at your bug report, do you mean you want to create a new .ods file in a not-yet-existing subdirectory? I.e., do you want that new subdir to be created on-the-fly automatically when writing to a new .ods file?
I don't know if that is at all possible with zip; or even on Linux for any program. On Windows it sometimes works for some programs, but surely not for any program either.

If that is indeed what you mean it looks to me to be an upstream bug; it would be better to file a bug report (or feature request) with the zip project then.

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Mon 11 Aug 2014 12:48:26 AM UTC, comment #4:

Hi, and thanks for looking into this.
If you mean the octave GUI, I have always only tried this with the command-line interface than the GUI, and that's where I always received the error as described.

Peter P. <p8rpp>
Fri 08 Aug 2014 09:25:32 PM UTC, comment #3:

To the OP:
Do you also get zip errors with the CLI (command line interface rather than the GUI)?

I can more or less reliably get zip errors when using the GUI; it doesn't happen with the CLI. I begin to suspect it is a problem with the GUI, i.e., with syncing directories.

When I'm back home (I'm on holiday now) I'll investigate further.

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Thu 31 Jul 2014 01:06:06 PM UTC, comment #2:

ATM (with io-2.2.2) this works OK on my Windows 7 box. But I'll check again on Linux later. When I'm back home I can also try network drives.

I suspect timing issues play some role here. While in the relevant private ods write routine the zip command is invoked using eval() and eval() is instructed to wait for zip's output status, nobody knows if the low-level I/O invoked by zip might be scheduled for later (viz. "lazy write"). So zip itself can easily get confused.

FYI: the io package contains a few test routines; you can see that in io_ods_testscript.m (and the overall test script test_spsh.m) several sleep() commands had to be inserted to allow the script to run properly, i.e., to avoid zip to stumble over its own feet.

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Wed 16 Jul 2014 09:04:30 PM UTC, comment #1:

Can't confirm this one, but I know it doesn't work reliably ATM.
Related to bug #42783

FYI the people here reserve the term "crash" for when Octave itself disappears with a segfault or so.
If you get errors but Octave lives on an still accepts commands it simply is "incorrect result".

Philip Nienhuis <philipnienhuis>
Project MemberIn charge of this item.
Tue 15 Jul 2014 10:47:54 PM UTC, original submission:

odswrite currently fails when writing to an .ods file that is not in octave's working directory. This is using the 'OCT' interface and the octave-io 2.2.2-1 package using the zip 3.0 Package on Debian.

Example call of odswrite:

The error message is

Interestingly the return value of odswrite indicates success (=1).



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by p8rpp (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-08-13 philipnienhuis StatusNeed Info => Wont Fix
        Open/ClosedOpen => Closed
    2014-08-08 philipnienhuis StatusIn Progress => Need Info
    2014-07-31 philipnienhuis StatusConfirmed => In Progress
    2014-07-16 philipnienhuis Item GroupSegfault, Bus Error, etc. => Incorrect Result
        StatusNone => Confirmed
        Assigned toNone => philipnienhuis
        Release3.8.1 => other
        Operating SystemGNU/Linux => Any

    Back to the top

    Powered by Savane 3.3