redirect not working and host says its not their problem

[MHulak]

My host server came through. They asked me for a sample to test and ensure it is working. I tested it and it seems working fine now. the pub dir is getting the symlink on each download and no more access issues.

i asked them to explain where the problem was and i will post it once i here back from them

i appreciate all the help and support given here. i had a choice of ecommerce solutions. it is obvious i chose the right one.

[RodG]

Here is where I am at to clear up all confusion.

Or cause more

Details about .htacess

<IfModule mod_headers.c>
<FilesMatch ".*\.(zip|ZIP|gzip|pdf|PDF|mp3|MP3|swf|SWF|wma|WMA|wmv|WMV|wav|epub|JPG|jpg)$">

These tags require maching closing tags

</FilesMatch>
</IfModule>

Furthermore, unless there is something placed in between the <FilesMatch> and </FilesMatch> then this section does nothing.

For Apache2 or later the following is recommended:
ForceType application/octet-stream
Header set Content-Disposition attachment

What this does is to force the "Save As" dialog box when the user click on the download links. Without it, unless the mime_types is correctly set, the files could be printed directly to screen as 'raw data'.

Details about PUB generated SymLinks
The Pub folder with 777 permissions gets created along with the link within properly

The Pub folder should already exist. It is only the 'hidden' files/link that gets created upon purchase of a downladable product.
777 folder permissions may cause some servers to crash. 755 or 775 is better (as long as they work).

As I mentioned before, I may appear to be a little(?) pedantic about these things, but a computer is generally far more pedantic and considerably less forgiving.

Cheers
Rod

[MHulak]

the htaccess files had closing tags and all. i just posted the changes.

anyways, my server responded saying the issue was

Our system administrators changed the path in the code (as we described earlier the path should be something like this 'ln -s ../download/wallpaper/...'). We set this for your files and the problem is resolved now. We are glad to know that you are satisfied from our service.

[RodG]

the htaccess files had closing tags and all. i just posted the changes.

I thought that was probably the case, BUT some/many people do take these things literally, and it would be easy to assume that since you didn't show them then they probably aren't needed.

anyways, my server responded saying the issue was

Our system administrators changed the path in the code (as we described earlier the path should be something like this 'ln -s ../download/wallpaper/...'). We set this for your files and the problem is resolved now. We are glad to know that you are satisfied from our service.

I really don't wish to cause you pain or distress, but this puts me a little on edge. There *shouldn't* be any need for your system admins to have put in any such links in the first place, and when they state "We set this for your files and the problem is resolved now" makes me even more nervous because we have no way of knowing what their 'new settings' are. Have they added another needless link?

Being the devils advocate, and looking at the worst possible scenario, let us assume you have something like this:

/download/wallpaper/somefile.jpg

and another like /download/portraits/somefile.jpg

If your host has made a symbolic link from /download/wallpaper/ to /download/ (which will take care of your 'wallpaper' files), then what do you think is going to happen if the download is for the /portrait/somefile.jpg file (which probably doesn't have this same 'fix') ?

I'm NOT saying that this IS the case, but if it were, you will soon run into even more (needless) problems. It would be wise for you to test this scenario just in case. It will be easier to rectify the problem while it is still 'fresh' than have to start another thread or open another support ticket in a few weeks time where the whole cycle will start again.

Cheers
Rod

[MHulak]

The system administrators added the following lines :

222 // make link via relative path:
223 $link_create_status = @symlink('../../download/'. $origin_filename, DIR_FS_DOWNLOAD_PUBLIC . $tempdir . '/' . $download_link);

in your '/home/www/michaelhulak/includes/modules/pages/download/header_php.php' file and disabled/commented the 220 line of the same file.


I tested this with the original subdirectories and files with spaces in it and they too work. I put Yellow Trout Lily in Toronto 1.94 MB Flower_Macros/2012 04-18 IMG_2088.zip in Flower Macros $0.00 to show and test

[MHulak]

was the dir fs download path was faulty.

i have what i believe was generated upon installation

define('DIR_FS_DOWNLOAD', DIR_FS_CATALOG . 'download/');
define('DIR_FS_DOWNLOAD_PUBLIC', DIR_FS_CATALOG . 'pub/');
define('DIR_WS_UPLOADS', DIR_WS_IMAGES . 'uploads/');
define('DIR_FS_UPLOADS', DIR_FS_CATALOG . DIR_WS_UPLOADS);
define('DIR_FS_EMAIL_TEMPLATES', DIR_FS_CATALOG . 'email/');

[RodG]

The system administrators added the following lines :
223 $link_create_status = @symlink('../../download/'. $origin_filename, DIR_FS_DOWNLOAD_PUBLIC . $tempdir . '/' . $download_link);

I'm undecided as to whether to call them idiots or too smart for their own good.

They've modified one of the core files in order to fix a user error in one (or both) of the configure.php files.
I hope you have a very good memory, because in 6 or 12 months time (or whenever the next zencart update is released) you will need to remember and re-implement these changes. It would be FAR easier to fix the configuration error and you'll never have to worry about it again.

I tested this with the original subdirectories and files with spaces in it and they too work. I put Yellow Trout Lily in Toronto 1.94 MB Flower_Macros/2012 04-18 IMG_2088.zip in Flower Macros $0.00 to show and test

I think the fact that this worked is more luck than anything else. The file that gets downloaded is called "2012_04-18_IMG_2088.zip", so *something* has converted the spaces to underscores for you.
On a personal level, I think this is a horrible filename... Call me strange if you like, but If were to purchase a downloadable product called "Yellow Trout Lily" I would actually be expecting to download a file with a similar name, eg YellowTroutLily.zip .. I'd have a heck of a time finding this file when it's called "2012_04-18_IMG_2088.zip". Heck, the date doesn't even reflect the date I downloaded or purchased it.

Unlike most of my previous input, this one is just personal opinion rather than technical requirements.

Do with this what you will.

Cheers
Rod

[DrByte]

Here is where I am at to clear up all confusion.

The server is Apache so SymLinks should work. It is not a Windows server.

History:
SymLinks were working before. I am not sure when they stopped working. One major change I noticed was one day I got the "zencart new install screen" The solution to get the page back up and running was from /srv/disk1/8133219/www/michael to /home/www/michaelhulak/. After getting the page back up and running, I did a once over the page and discovered the SymLink downloads were no longer working.

So, clearly your host changed how/where your data is stored on your server.
And in the aftermath of trying to fix the mess created by doing that, you or they neglected to update all the paths properly in your configure.php files to reflect the new locations of files/folders.

[MHulak]

i originally asked then this.

Subject: DIR_FS_CATALOG

SatMay 5 2012 4:19pm
last night my www.michaelhulak.com was working correctly. this morning the page was not working. after some time i got it working again.

was my folder/directory information moved or changed? what happened to my page last night? will this happen again?


SatMay 5 2012 4:28pm - Paul Allen Rate this answer: (Poor) (Excellent)
Hello Michael,

Thank you for contacting us.

Please be informed that we never modify/move/delete or do any interaction whatsoever on our customer's accounts without their consent and knowledge.

Whatever it was, it was not caused by a direct or indirect action from our side. If this happens again, please let us know immediately and do not take action to repair the site so we can investigate and find the possible cause.

[RodG]

Please be informed that we never modify/move/delete or do any interaction whatsoever on our customer's accounts without their consent and knowledge.

Whatever it was, it was not caused by a direct or indirect action from our side. If this happens again, please let us know immediately and do not take action to repair the site so we can investigate and find the possible cause.

The solution to get the page back up and running was from /srv/disk1/8133219/www/michael to /home/www/michaelhulak/.

One of these contradicts the other.

Who provided this solution?

Cheers
Rod

PS. For what its worth, /srv/disk1/8133219/www/michael was a problem just waiting to happen. You should never have used it in the first place (unless the server was misconfigured)