This is real beauty. We have multiple Umbraco instances in multiple environments. When uploading a certain image Umbraco gives "An error has occurred".
So its a bad image? Nope, I have managed to create a suite of four images that demonstrate the issue based on PNG complexity. Tried re-saving the image in different image programs and varieties.
This never happens with JPG files and only when DFS is used to replicate the media folder.
First thought was file size. Nope, can upload images up to 50mb before the error states clearly that the file exceeds 50mb. Problem image is 1.4mb
When the error occurs procmon will note a "SHARING VIOLATION" (path is the thumbnail) that does not appear when a working image is uploaded. But numerous investigations show that "SHARING VIOLATION" for DFS environments is not and error.
Indeed, the image file plus expected thumbnails are physically created and replicated. The App_Data\Temp\FileUploads however fills up with the failures, successful uploads are correctly removed.
Here are four PNG images 1280x800. Each time I attempted to upload these I repeated it three times to ensure consistency.
"random 1292x800.png" random pixels - Always fails in DFS environment
"uniform black 1292x800.png" solid black - Always succeeds in DFS
"random 1292x800 3 450px.png" random pixels with 450 pixels with
white block on left - Always fails in DFS environment
"random 1292x800 3 550px.png" random pixels with 550 pixels with white block
on left - Always succeeds in DFS environment
Only the media folder is DFS, all the rest is local to each instance. Only a single machine per environment is a master and can be used to upload media items. DFS access is via a name space UNC path.
ERROR Umbraco.Web.WebApi.Filters.FileUploadCleanupFilterAttribute - Could not acquire actionExecutedContext.Response.Content
ystem.NullReferenceException: Object reference not set to an instance of an object.
at Umbraco.Web.WebApi.Filters.FileUploadCleanupFilterAttribute.OnActionExecuted(HttpActionExecutedContext actionExecutedContext)
I suspect the underlying problem will be the image manipulation done on upload, not the upload itself. I'm 7.7 we don't generate thumbnails anymore because those should be lazily generated by image processor. Are you able to test with the very latest version of umbraco?
Not much uses those old thumbnails anymore which is also part of the reason we removed them.
What I mean about testing 7.7 is if you can replicate this issue simply by using these images, could you just install a vanilla 7.7 version on your local machine and test it to see if the problem has gone away? I don't mean testing this on your full blown solution. I also assume you can replicate this issue on a vanilla 7.5.12 solution?
I'm unsure about disabling them on old versions, i'd have to go dig in the source to see if that's possible.
Specific complexity PNGs fail to upload with DFS
This is real beauty. We have multiple Umbraco instances in multiple environments. When uploading a certain image Umbraco gives "An error has occurred".
So its a bad image? Nope, I have managed to create a suite of four images that demonstrate the issue based on PNG complexity. Tried re-saving the image in different image programs and varieties.
This never happens with JPG files and only when DFS is used to replicate the media folder.
First thought was file size. Nope, can upload images up to 50mb before the error states clearly that the file exceeds 50mb. Problem image is 1.4mb
When the error occurs procmon will note a "SHARING VIOLATION" (path is the thumbnail) that does not appear when a working image is uploaded. But numerous investigations show that "SHARING VIOLATION" for DFS environments is not and error. Indeed, the image file plus expected thumbnails are physically created and replicated. The App_Data\Temp\FileUploads however fills up with the failures, successful uploads are correctly removed.
Here are four PNG images 1280x800. Each time I attempted to upload these I repeated it three times to ensure consistency.
Only the media folder is DFS, all the rest is local to each instance. Only a single machine per environment is a master and can be used to upload media items. DFS access is via a name space UNC path.
Set web.config:
but made no difference to
And tried Umbraco 7.4.3 and 7.2.4
To me this sounds like a timing issue directly related to the time taken to process the PNG image.
But where do I go to fix it? Losing DFS is not an option.
This has to be to weirdest issue I have ever come across.
forgot to mention, with logging on I see
in the Umbraco log.
But researching that indicates its not an issue.
I have seen this issue also with DFS and pngs only, cross reference with my comments on YouTrack http://issues.umbraco.org/issue/U4-6334
setting
<add key="aspnet:UseTaskFriendlySynchronizationContext" value="false" />broke all media file uploads.
I am only ever uploading one file at a time and not using drag and drop.
had to give up and upload a different file then manually update the physical file.
Hope this does not come up to often. I notice our designers are using bigger and more detailed background images for new sites. {worried smiley}
Hi, did you ever out a proper solution to this issue?
We're using version 7.5.12 and are having this issue in DFS, the files you provided fit the cases on our server as well.
I suspect the underlying problem will be the image manipulation done on upload, not the upload itself. I'm 7.7 we don't generate thumbnails anymore because those should be lazily generated by image processor. Are you able to test with the very latest version of umbraco?
Unfortunately we cant test it with 7.7 right away.
Is there any way to disable the thumbnail generation, and what penalties would we get from it?
Not much uses those old thumbnails anymore which is also part of the reason we removed them.
What I mean about testing 7.7 is if you can replicate this issue simply by using these images, could you just install a vanilla 7.7 version on your local machine and test it to see if the problem has gone away? I don't mean testing this on your full blown solution. I also assume you can replicate this issue on a vanilla 7.5.12 solution?
I'm unsure about disabling them on old versions, i'd have to go dig in the source to see if that's possible.
The issue only shows itself on environments with DFS enabled.
Ah, of course silly me
is working on a reply...