Unable to download attachments in new BE2.6 installation - 404 error

Jul 18, 2012 at 8:31 PM

I create a post with a file attachment.  When I click the file attachment link, I receive error '404 - File or directory not found.'.  The file did upload correctly, as I can see it in the file system. 

While troubleshooting, I installed a vanilla test instance, granted NETWORK SERVICE permissions to the APP_DATA directory, logged in as admin, set up a shell blog, and created a shell post with an attachment.  The same error occurs. 

As indicated in this discussion thread (http://blogengine.codeplex.com/discussions/361675), if I change the attachment URL from 
http://myserver/mysite/myblog/FILES%2f2012%2f07%2ftest.txt.axdx to
http://myserver/mysite/myblog/file.axd?file=%2f2012%2f07%2ftest.txt, I can then download the file, so it appears to be a URL issue rather than a permissions issue. 

Can anyone suggest a resolution to this problem? 

TIA

BlogEngine 2.6
W2K8 Ent, IIS 7, Integrated Pipeline

Aug 10, 2012 at 11:55 AM
Edited Aug 10, 2012 at 11:56 AM

in the BlogEngine.Core.FileSystem File

 public string FileUrl
        {
            get
            {
                return string.Format("{0}file.axd?file={1}", Utils.RelativeWebRoot, this.SafeFilePath);
            }
        }

 

 

then it will work

 

Enes

Aug 10, 2012 at 4:25 PM
Edited Aug 22, 2012 at 12:02 AM

Thanks.

Your post gave me the correct file, but I actually had to make a slightly different mod to make this work in build 2.6.0.5. Note that this did not correct existing attachment paths - it only affects newly created attachment paths.  

        /// <summary>
        /// gets the full download path to the file, using the file handler
        /// </summary>
        public string FileDownloadPath
        {
            get
            {
                // return string.Format("{0}FILES{1}.axdx", Utils.RelativeWebRoot, this.SafeFilePath);
                return string.Format("{0}file.axd?file={1}", Utils.RelativeWebRoot, this.SafeFilePath);
            }
        }

Interestingly, it looks like the file BlogEngine.Core.Web.HttpModules UrlRewrite.cs should be handling this rewrite, but it isn't working. 

            if(url.Contains("/FILES/") && url.Contains(".AXDX"))
                RewriteFilePath(context, url);
	...
Aug 17, 2012 at 2:14 AM

Yes you are right 

Actually UrlRewrite.cs should do this but it doesnt do but i tried to solve it like this but i didnt work so i did my way as i showed before

 

Enes

Nov 2, 2012 at 10:55 PM

sorry but where is this file? what is the path?

Nov 5, 2012 at 10:53 AM

i have stille the same problem ... someone can tell me where is public string FileUrl?????

what is the file?

Nov 5, 2012 at 3:06 PM

the error is in filesystem File.cs :

public string FileDownloadPath
{
        get
           {
               return string.Format("{0}FILES{1}.axdx",   Utils.RelativeWebRoot, this.SafeFilePath);
           }
} 


it's possible to change in blogengine.core.dll???

Nov 5, 2012 at 3:13 PM
Edited Nov 5, 2012 at 3:15 PM

You will need to download source to find this file: 

\Source\BlogEngine\BlogEngine.Core\FileSystem\File.cs

Edit the source as indicated in previous posts, rebuild the project, and replace with the rebuilt dll. 

Nov 5, 2012 at 3:46 PM

Thanks for reply azzurij but where is the link of source?? what is the step to edit source - rebuilt the project and replace ??

i must to install Visual studio? and then? how load a file .dll like blogengine.core.dll?

i'm in confusion!

Coordinator
Nov 5, 2012 at 4:37 PM

Generally speaking, I would not recommend making changes to core DLL unless you know really well what you are doing. It is a "last resort" action and might do more harm than good.

I understand it can be frustrating when you having an issue and nobody can help. This usually because you run into something specific that others not familiar with or people don't understand your issue clearly and don't feel comfortable to answer. For example, I have no idea what you are using, what you trying to do and what is not working.

The original post was about plain 2.6 with probably XML provider having issue with attachments and it was fixed long ago in the source repository. Did you try to upgrade to 2.7 and check if you still having same issue?

Nov 5, 2012 at 5:21 PM

Ok Rtur thank you for reply.

you're right about not changing core DLL, but is also interesting to understand all features and capabilities of BlogEngine.net i don't think it's a bad thing (i always do the first a backup).

Now i'm using blogengine.net 2.6.0.18 and before to change again i will want to fix errors of this version and then to change... that's all... 

My problem is explain in title of this discussion "Unable to download attachments in new BE2.6 installation".. when i upload a file and save post... i try to open the file uploaded and i get error 404..   the file has extension .axdx, like explained in previous post of this topic..  in be 2.5 the extension was axd

do you think that i must to upgrade to version 2.7?  also if i have only this problem?

Thank you

Fabry

 

 

 

 

Coordinator
Nov 5, 2012 at 7:14 PM
Edited Nov 5, 2012 at 7:19 PM

If this is possible, definitely start by upgrading instead of fixing issue(s) that already fixed in 2.7. That specially true for this very issue because in 2.6 we added "file manager" which uses that ".axdx" extension, and then fixed few reported bugs this change introduced.

If you want to play with source code, you can download and unzip source version from "downloads" tab, it is labeled "BlogEngine.NET 2.7 (source)".

You need visual studio 2010 (free web developer works fine, just make sure you pick "Visual Web Developer 2010 Express" version).

When installed, you can double-click solution file (BlogEngine.sln) to load it in VS, right-click BlogEngine.NET, set it as startup project and run.

Nov 5, 2012 at 8:46 PM
Ok rtur thank you very much and very compliments for your work in this forum.

-----Original Message-----

From: rtur
Sent: 5 Nov 2012 19:14:45 GMT
To: [email removed]
Subject: Re: Unable to download attachments in new BE2.6 installation - 404 error [blogengine:374360]

From: rtur

If this is possible, definitely start by upgrading instead of fixing issue(s) that already fixed in 2.7. That specially true for this very issue because in 2.6 we added "file manager" which uses that ".axdx" extension, and then fixed few reported bugs this change introduced.

If you want to play with source code, you can download and unzip source version from "downloads" tab, it is labeled "BlogEngine.NET 2.7 (source)".

You need visual studio 2010 (free web developer works fine).

When installed, you can double-click solution file (BlogEngine.sln) to load it in VS, right-click BlogEngine.NET, set it as default project and run.

Apr 16, 2013 at 4:37 PM
I have tried this with 2.7 and it still does not work. I originally started with the Web install of 2.7, but downloaded the source for 2.7 and rebuilt. I copied all the DLL files back up to the bin directory, recycled the appPool and it continues to make the URLs wrong. Is the URL supposed to have .axdx at the end? If so then I guess the URL isn't wrong, but it doesn't work. I have verified that the file is uploading okay, its in App_Data/files/2013/04/

Any suggestions?
May 22, 2013 at 7:56 PM
I just upgraded to 2.8. I followed the exact instructions by starting with a fresh install etc. I still get this issue:

http://my.?????.com/forum2/FILES%2f2013%2f05%2fX%27s+and+O%27s+Women%27s+Merchandising.pdf.axdx

Its still writing the URL wrong... this is the correct URL: (Close)

http://my.?????.com/??????/forum/file.axd?file=2013%2f05%2fX%27s+and+O%27s+Women%27s+Merchandising.pdf

Whats the deal? (note the ?????? I replaced)
May 24, 2013 at 9:55 PM
Me too facing same issue.. I tried and added even the mime types for .axd and .axdx at hosting server.

http://www.ssnair.net/FILES%2f2013%2f05%2ftestupload.txt.axdx

But still getting 404 error. Even I posted another discussion, but nobody bother to help still..

404 - File or directory not found.
The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.