Developer forum

It it helps, here is the StackTrace error:


    Stack trace:    at System.IO.PathHelper.GetFullPathName()
   at System.IO.Path.LegacyNormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
   at System.IO.Path.GetFullPathInternal(String path)
   at System.IO.FileInfo.Init(String fileName, Boolean checkHost)
   at Dynamicweb.Imaging.ImageHandling.ConvertCache.get_SourceFileChanged()
   at Dynamicweb.Imaging.ImageHandling.ConvertCache.get_CacheFileVirtualPath()
   at Dynamicweb.Admin.ProcessImageHandler.ProcessImage()
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

I do not think this is related to webp.

Are you missing some info from the stack trace? When you see the 500 response code in dev tools, take a look at the entire stack on the http response of the 500.

What happens if you use another format? Seems like an issue with locked newly uploaded images - maybe locked by AV?

BR Nicolai

Hi Nicolai,

The .png format works well. What we have also noticed that the 500 Error is temporary. The link may render 500 and then start working after half an hour or so.

I am not sure where to start investigating.

Thank you,
Adrian

Where is this hosted? I think it is related to permissions or locking of temp files or similar and is a server setup issue.

Using webp goes through a another compression engine than PNG, and they might use different temp folders and read lock logic.

Hi Nicolai,

Your suggestion makes sense. We are handling the hosting for this solution.

We have not seen it before in any of our hosted solutions, and that's why hosting was not the first thing we had in mind.
Any way I can figure out the temp folder for the webp images?

Thank you,

Adrian

Looking at your stack again, it is when reading the last changed date of Cache.net/Images folder of that image.

Hi Nicolai,

I am coming back to this thread as I could not identify the issue.

I have investigated the permissions and I could solve some situation, but I am still having issues when using Webp.

The error I am getting now is this:

And it only occurs if we are trying to output image as WebP. Am I missing a configuration? Could it be some leftovers from an older version of DW?

Thank you,

Adrian
 

Hi Nicolai,

Can you have a look at this issue, please?

I can't figure out the issue.

Thank you,

Adrian 

Hi Adrian

We need a copy of the entire solution in our dev environment and we need it reproduced there. We do not have access to your host.

I am pretty sure this is a server related issue - but we cannot debug this for you if it is not in our environment (and my guess would be that it cannot be reproduced here). But we have to test that.

When googling the "no such file or directory" exception, what I see is missing permissions from the windows box user executing the request. So if you see this exception on a website, that website runs in an app-pool with an identity - and that identiy do not have sufficient permissions to write to some folder on your box - could be temp, could be somewhere under /files solution.

It can be broken permission tree in your folders.

Depending on what user your app pool is running under (default is app pool identity), you can try to switch the app pool to "network service" or "System" which has elevated previliges. If that makes it works you have verified it is a permissions issue.

Also on the window box, you have the windows eventviewer which could reveal the underlying cause - pls. look at that.

The reason you might only see this for webp is that webp is using an other encoder than jpg and gif - the webp encoder is a google based code base, and it might use a different temp folder or something to handle the encoding....

BR Nicolai

Thank you very much, Nicolai.

This is very useful.
We have tried finding the error message in the ImageGlue provider without any luck.

The mind-boggling thing is that the error is not permanent. It can work very well for a few weeks, and then it fails. And it seems to only fail for some image sizes and not for all.
Most probably, there is an issue with generating new cached versions of that image.

For now, we'll have to try and debug it locally and if we cannot fix it, we'll get back to you with a copy of the solution.

Thank you,
Adrian