On Apr 8, 2015, at 5:28 PM, Christoph Becker wrote:
Jeffry Killen wrote:
On Apr 8, 2015, at 3:04 PM, Christoph Becker wrote:
Jeffry Killen wrote:
My question is: Where is the test.zip archive file located? (/tmp,
maybe?)
I would expect it to be in the same dir as the processing script,
but I
don't see anything in the dir
by the name of test.zip.
I might be completely wrong, but I believe that the actual
test.zip is
only created if everything worked out fine (including that the zip
won't
be empty). So unless you're getting "good to go: ...", there
won't be a
zip file.
If everything works well, the file is supposed to be created in the
current working directory, i.e. the usually the directory of the
requested script.
Thank you for the inro:
As it turns out, the cwd of the script did not have adequate write
permissions set.
Once I corrected that problem I got the test.zip file to show up.
But I am wondering why I did not get the error code:
ZIPARCHIVE::ER_OPEN
Can't open file... if write permissions where wrong?
I agree that there should be some error indication (not sure if
ER_OPEN
would be appropriate when creating a file, though) instead of
returning
TRUE. Did you get any warning/notice in the error log (presuming that
you have error_reporting set to an appropriate value for development)?
Also, maybe the error is reported only when ->close() is called. It
might be worthwhile to check its return value.
Unfortunately, I can't easily try it myself because I'm on Windows 7
Home, where I do not easily have access to the ACL (it was possible
with
XP, but I had to reboot into safe mode; don't know if that's possible
with Win7). Maybe you want to spend some further time on the issue
and
file a respective bug report[1] if appropriate.
I didn't get an error message saying that write permissions denied the
operation.
I didn't have @ in front of the call to open and have error reporting
turned on.
Anyhow this is a process of getting to know what to expect and coding
for it.
I would add code to test the write permissions for the dir: like
if(is_writable('./'))
and proceed based on test result.
I ran across user comments on the php.net site for ZipArchive
claiming that
addEmptyDir was remove or disabled, and in fact I couldn't get it
to work.
I just tried that with PHP 5.4.19, and it worked fine. I can imagine,
though, that empty directories might not be displayed by all zip
readers, and actually I'm not sure if zip archives do store
directories
at all; quite likely only files are stored. Anyhow, the issue seems
to
demand further investigation. It seems there are no respective
reports
in the PHP bug tracker.[2]
Actually the only reason I can see for adding an empty directory to a
zip file
is to add something to it at a later date. But when I used it I did
not get any
errors. The script just seemed to exit WITHOUT returning ANY async
response.
I was probably doing something wrong that didn't cause an error, or my
code
wasn't managing to pass error information back.
I also discovered that calling download code from an async get
request
wouldn't
work. I just got the contents of the zip file returned to the origin
page (as I coded it
in the original message).
That's to be expected. If you use XMLHttpRequest (or a wrapper) to
request a download, the response can be received, but it can't be
stored
in the file system of the client due to security considerations.
Thanks for time and attention:
You're welcome.
[1] <https://bugs.php.net/>
[2] <https://bugs.php.net/search.php?cmd=display&search_for=addemptydir
>
--
Christoph M. Becker
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
