Downloads deliver an empty zip file

Everything is working fine with the downloads except that the zip file shows up with nothing in it.

I do have downloads by redirect turned on and what I have discovered is that there is nothing in the pub directory for those redirects. as the documentation says there should be. There is one folder named .ulcwvnoxjdtmrhrirl but it is empty.

This is a linux server, the folder permissions were set to 777 (and actually 755 should work as well). These zip files are very small.

This started happening after changing servers but don't know what to tell tech support - what server setting would create this problem?

My tech support is telling me this is a zen cart problem - not a server related issue. Why would this stop working after moving the cart if it's not a server issue?

delia:

My tech support is telling me this is a zen cart problem - not a server related issue. Why would this stop working after moving the cart if it's not a server issue?
Exactly.

Thanks for that confirmation. Grrrr......

delia:

Everything is working fine with the downloads except that the zip file shows up with nothing in it.Do you mean it's zero bytes? Or that it's got content that cannot be unzipped?
delia:

Everything
I do have downloads by redirect turned on and what I have discovered is that there is nothing in the pub directory for those redirects. as the documentation says there should be. There is one folder named .ulcwvnoxjdtmrhrirl but it is empty.

This is a linux server, the folder permissions were set to 777 (and actually 755 should work as well). These zip files are very small.

This started happening after changing servers but don't know what to tell tech support - what server setting would create this problem?

With download-by-redirect, Zen Cart does the following very simple process:
a) generates a random foldername under /pub/
b) calls the PHP function to generate a symlink from the file in the /download/ folder to that new folder under /pub/ ... thus becoming /pub/.abcwhatever/filename_to_download.zip
c) and then redirects the customer's browser to that file under the pub folder, leaving it entirely up to apache (webserver engine) to do the download/delivery of the file entirely independent of PHP

So, if the server doesn't support symlinks, step b won't work. Some older PHP versions didn't support it because of filesystem/OS limitations, especially on windoze servers. If permissions prevent the creation of the folder or the generation of the symlink stub, then of course you've got a problem. If your filesystem can't handle symlinks, then you've got a dud hosting service, and will have to use an alternate delivery method - Zen Cart has 3 modes, each with varying security implications and server resource (CPU/RAM) demands.

zero bytes, it opens but there's nothing there.

This is a dedicated server and they are going to have to fix.

So they had disabled the php readfile function the server. More secure but unusual.

delia:

So they had disabled the php readfile function the server. More secure but unusual.
Yes, a little unusual.
In considering workarounds, note that: That would only be a problem if Download By Redirect was off, or if symlink creation failed (due to server's inability to create symlinks, or permission problems) and Download By Streaming is off.

hmm, I had found error logs in the cache about the readfile error and assumed. So I assumed wrong?

I ended up using download by streaming as my files are very small but still want this working server wide in case it comes up with a client.

I would have had download by streaming off and redirect on at the time.

delia:

I would have had download by streaming off and redirect on at the time.So, if Redirect was set to on, but the server's configuration wasn't allowing the symlinks to be created, it would failover to attempting to deliver the file directly, thus triggering your readfile problem. By turning on Download by Streaming it bypasses the attempt to use readfile and instead stream it in smaller chunks.

exactly, well, I'm pretty sure that was what was happening. I would have to test again to be absolutely sure.

Would you mind testing this code alteration?

1. First test that using readfile is still broken.
2. Make the following code change to /includes/modules/pages/download/header_php.php
3. Test the same download as you did when readfile was broken ... this time it should work.

Code:
Around line 224 of that file you should see this:if (DOWNLOAD_IN_CHUNKS != 'true') {Change it to this:```
[B] $disabled_funcs = @ini_get("disable_functions");[/B]
if (DOWNLOAD_IN_CHUNKS != 'true'[B] && !strstr($disabled_funcs,'readfile')[/B]) {

and now it works!

Okay, so with the download streaming turned off and download by redirect turned on, I had to use the additional code.

If I turn on download streaming with download by redirect on - without the additional code, it does work.

But it says that shouldn't change it.

The code fix I posted should simply provide a safe fallback in the event that readfile is disabled. Everything else should work as normal.

So if I have downloads by redirect and downloads by streaming, it's supposed to be using the redirect? Because without the code that way it works.

If I turn off download by streaming, it only works with the additional code.

Yes, that makes sense. (Because it's clear that your server isn't successfully doing any "download by redirect" at all, regardless of it being on or off)

Thanks for helping me clarify this!

Now I have to make a decision about whether to enable readfile or not or try to remember this discussion the next time it all crops up again!

We'll look into building that fix into a future release since it's a minor bug, albeit one that's only triggered by an unusual, uncommon server configuration.

We'll look into building that fix into a future release since it's a minor bug, albeit one that's only triggered by an unusual, uncommon server configuration.

In my experience "Download by redirect" doesn't work on any server running PHP as a CGI with either SuPHP or SuExec in place.

Additionally the most recent release of Apache 2.2 has tightened up security considerably on the "on the fly" creation of symlinks by site owners - because they could be misused by hackers.

Vger