Disappearing images as well as "failed to export file from provid

November Happy Hour will be moved to Thursday December 5th.

AI OnAI Off

Home / Forums / Developers (Main Products) Forum / CMS 7.5 - 11 /

Disappearing images as well as "failed to export file from provide epi.fx.blob"

fuji

Vote:

Hello all,

recently we noticed that some images had disappeared from pages. We're not sure why, when, and how many of them and which exactly. For now it looks just randomly. However it came to our attention just right now.

I don't think it maybe some editor mistake or corrupted file, because our editors are re-checking newly created pages instantly, so they would notice if any image would not be accessible from the very first publish of the page. There were ideas to blame server, but still, some abstract blames towards server issues...

Log message:

2020-08-07 16:55:50,617 [107] ERROR EPiServer.Global: Unhandled exception in ASP.NET
System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Applications\***\Web\App_Data\blobs\0d4afbe3d64145cabcb43835567677df\cc170be8ede143239e185941fb3b2703.jpg'.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
   at System.Web.HttpResponse.TransmitFile(String filename, Int64 offset, Int64 length)
   at System.Web.HttpResponseWrapper.TransmitFile(String filename)
   at EPiServer.Web.BlobHttpHandler.ProcessRequestAsyncInternal(HttpContextWrapper context, AsyncCallback cb, Object extraData)
   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)

Any ideas where to start to digging in much appreciated!

Also, when we try to copy/paste some pages, we're facing "failed to export file from provide epi.fx.blob" error message - but this one is not that common as disappearing images.

Screenshot - https://i.imgur.com/np0G9qe.png - any ideas what may be wrong?

CMS version 11.

Thank you!

#226211

Edited, Aug 07, 2020 14:55

Cory Kratz

Vote:

We are running into this issue as well. The only thing I can think of is that we DID have image fields at some point, but they were removed and changed to image URLs to handle a non-integrated DAM solution.

Did you have any similarities to this?

#226956

Aug 24, 2020 23:00

Cory Kratz

Vote:

I found a solution to this and we're running some tests on it right now. Essentially, because we changed the fields from an Image field to a String field, the old versions of the page that were created with these image fields still link to the file "blobs" in the database and I can't find an easy way to unlink these pages from those blobs.

What we were able to do, was:

1) export the page (it will give a warning, similar to your error message)

2) Rename the episerver exported files with a .zip extension

3) remove the epiMedia.xml file

4) Edit epix.xml and remove the <RawProperty> ...</RawProperty> tags that reference the blobs as well as the <files> ... </files> tags at the bottom

5) Zip up the files, as filename.episerverdata and remove the .zip extensions

6) Import the page but uncheck "Update existing content items with matching ID"

and you should now be able to copy/paste the newly created item. USE AT YOUR OWN RISK, as your scenario may be slightly different than mine. I would recommend testing this on a development machine.

#226995

Edited, Aug 25, 2020 14:22

fuji

Vote:

Thank you guys for your messages! We indeed had some work around DAM, however I think it did not touched Episerver blobs. What helped for us is simply restore App_Data/blobs folder with backed up version we had (or only missing folders - not sure here).

The idea around changed fields type makes perfect sense - I will check!

#226999

Aug 25, 2020 17:41

Cory Kratz

Vote:

Yes, the App_Data/blobs issue is slightly different for us as we are on a PaaS managed system, so our blobs are stored in the cloud. That does make sense though, although feels a little fragile.

#227000

Aug 25, 2020 18:08

Please login to post a reply