Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

PDF gets corrupted on download, but original file is ok?

Go to End

2 Posts   1224 Views


Community Member, 33 Posts

25 June 2010 at 2:37am

Edited: 25/06/2010 2:37am


I am rewriting a site for a client in SS. I have an odd issue with a single PDF file. On the filesystem, the file is fine and opens correctly. On the existing site, the file downloads correctly and opens correctly too.

However, when the file is downloaded by the user via the front end, the download file size drops from ~2MB to ~40KB, and the downloaded file is corrupt. However, opening it from the /assets folder works fine!

I am on OS X 10.6.4, but my users are testing on Windows with IE and have the same issue. Just that one file. Which was downloaded from the original site in the first place anyway, and which opens fine when downloaded via that original site!

Here is the original site page with the file for download:

The link code in my SS page is as follows:

<a href="assets/Uploads/FE_College_Knowledge.pdf" target="_blank">
    <img src="assets/Uploads/fe-careers-brochure.jpg" alt="Brochure" hspace="0" vspace="0" width="300" height="386" align="right" title="" />

I'd appreciate anyone's thoughts on this. Many thanks.


Community Member, 33 Posts

25 June 2010 at 4:09am

A quick update: the link code posted above is probably irrelevant as I also get the same issue when navigating to the file via the URL.

Could it be an issue with the fact that both my dev box (Mac) and the staging server (Linux) are *nix, whereas it's likely that the file was created under Windows. I can't think of a reason why this should be, but just in case somebody can go "aha! of course!" I thought I'd point that out.