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

Hi Adrian and Nicolai

Did you find a solution for this problem? I am experiencing something similar on a website running on v9.19.3. In my case, it is not isolated to webp though - the images might fail on all requested formats and sometimes work with webp while failing with png and jpg. Or work with jpg and fail with webp and png. Or other combinations. I hope you get the idea. So it is impossible to find a pattern.

Kind regards
Roald

Similar or the same?

Do you have an exception? Where is the site hosted?

Somewhere on the windows box in event viewer or inside Dynamicweb event viewer, you have an exception. That one is needed to figure out what it could be.

You site probably run as a app pool user - you can try to run using network services as that user has privilieged permissions.

It can be antivirus locking the source file or the temp file being written.

Without an exception it is hard to figure out.

BR Nicolai

Hi Nicolai,

The images from the imagehandler stop working periodically and start working again later. The failing images are available in the /images folder when the imagehandler is failing, and is also accessible on the raw path (e.g. domain.com/files/images/34-536x354.jpg).

Using the resource monitor on the server, I confirmed that no other process than the IIS process was using the images in the /files/images folder and in the /files/cache.net folder, while they were failing.

The error is as follows

An exception occurred while processing the file: /files/images/34-536x354.jpg
WebSupergoo.ImageGlue.Internal.IGException: Failed to export image: No such file or directory.   at WebSupergoo.ImageGlue7.XExport.#=qhXTvuijORjL0WbDCkf1rCA==(Canvas #=q5kjy3NWkbcwUkmCRGMQ0dw==, String #=qz2SEFQ2X3qO_JVq6PPNzzQ==)   at WebSupergoo.ImageGlue7.Canvas.GetAs(String inType, XExport inExport)   at Dynamicweb.Imaging.Providers.ImageGlueProviders.ImageGlueImageConverterProvider.Convert(ConvertParameters convertParameters)   at Dynamicweb.Imaging.ImageHandling.ImageConverter.ConvertInternal(ConvertParameters convertParameters)

Kind regards
Roald

It does look like a permission issue.I do not think it is locking the image itself - but imageglue uses a temp folder to generate the image and that is what gets locked or something like that. You could try to run the app pool of the website with the user 'network service'.

Dynamicweb 9 also have support for using another imageprovider - you can set that up in the backend to use ImageSharp:

Imagesharp is very different and faster. But it cannot create thumbnails of PDFs if you use that feature.

BR Nicolai