[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #42779] [OF] odswrite: "zip I/O error" when in
From: |
Philip Nienhuis |
Subject: |
[Octave-bug-tracker] [bug #42779] [OF] odswrite: "zip I/O error" when in different directory |
Date: |
Thu, 14 Aug 2014 18:55:34 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23 |
Follow-up Comment #8, bug #42779 (project octave):
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.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?42779>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/