SDL - The specified path, file name, or both are too long

Question

Looking for some insight, literature or experience out that describes ecl uri encoding.

We have a url that looks something like this that is imported via coreservices from s3 bucket into our CMS leveraging ecl

ecl:301-s3-abcdef!2D;ghijklmnop!2F;qrstuv!2F;wxyz!2D;abcdef!2D;ghijklmnop!2F;qrstuv!2F;wxyz!2D;abcdef!2D;ghijklmnop!2F;qrstuv!2D;abcdef!2D;ghijklmnop!2D;qrstuv!2D;wxyz!2F;abcdef!2F;ghijklmnop!2D;qrstuv!2D;abcdef!2D;ghijklmnop!2D;qrstuv!2D;wxyz!2D;abcdef!2D;ghijklmnop!2D;qrstuv!2D;wxyz!2D;abcdef!2D;ghijklmnop!2D;qrstuv!2D;wxyz!2D;abcdef!2D;ghijklmnop.jpg-fls-file

I am trying to understand where the !2D; or !2F; rather than - or / gets replaced respectively.

The reason I am asking is bc some of these path become lengthy and will throw a Windows Server-side error:

Tridion.ExternalContentLibrary.UI.Http.ThumbnailCache 
StoreImage 

System.IO.PathTooLongException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
at System.IO.PathHelper.GetFullPathName()
at System.IO.Path.LegacyNormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
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, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.File.InternalWriteAllBytes(String path, Byte[] bytes, Boolean checkHost)
at Tridion.ExternalContentLibrary.UI.Http.ThumbnailCache.WriteDataToFile(String path, Byte[] dataToCache)
at Tridion.ExternalContentLibrary.UI.Http.ThumbnailCache.StoreImage(Byte[] image, IEclUri eclUri, Int32 maxWidth, Int32 maxHeight, String thumbnailETag, String state, String addInNameAndVersion)

Tridion.ExternalContentLibrary.UI.Http.ThumbnailCache.StoreImage

and the only other scenario's that I've heard this happens in are:

1) When doing automated builds, there's redundant directories, so you have to rename them from "Some Big Path" to "SBP" or something similar to save space wherever possible

2) It happens when doing npm / grunt / node.js on Windows because of the recursive way it pulls down dependencies..

---

Seems like there is a limitation with ecl only allowing so many characters in a uri..

The problem is that by default, ecl uses the full path to create the temp thumbnail folder. And in Windows the max limitation is that within the folder the it is 260 characters.

Ideally, possibly an improvement for ECL could be the option of compress the name of the folder (based on the path to something shorter)?

---

It is also worth mentioning on publish I am seeing these errors on the server (using dxa generate dynamic ct & dynamic pt) for each ecl item published (one, after another):

EclProcessor: Input string was not in a correct format.

Component: Templating
Errorcode: 0
User: NT AUTHORITY\SYSTEM

EclProcessor: An error occurred while parsing the external metadata for ECL Item ecl:304-s3-abcdef!2D;ghijklmnop!2F;qrstuv!2F;wxyz!2D;abcdef!2D; ghijklmnop!2F;qrstuv!2F;wxyz!2F;abcdef!2D;ghijklmnop!2D;qrstuv!2D;wxyz!2D;abcdef!2F;ghijklmnop!2D;qrstuv!2D;wxyz!2D;abcdef!2D;ghijklmnop!2D;qrstuv.png-fls-file

Component: Templating
Errorcode: 0

User: NT AUTHORITY\SYSTEM

Answer 1

ECL URI's have a maximum length equal to the maximum length of a Component title. This limitation originates from the stub components having the ECL URI as the title.

The intended behavior when caching thumbnails is to stay within the 260 character limit on a file path by cutting the URI short in the name of the file used to store the cached image.

In order to limit collisions ECL will insert a hash code of the entire URI instead.

If this is not what you observe you need to contact support.

ECL server side caching details. ECL will store the full URI in the file containing the cached thumbnail (along with other information like provider version and etag).

When returning an item from disk cache ECL will check the full ECL URI against the value stored with the thumbnail. If the values do not match (so there is a hash code collision) it will regenerate the thumbnail from the provider and then overwrite the cached file.

So in theory you could have the server side cached item constantly changing between the two items with the collision. In this case the client side caches in the browser will maintain cache correctly limiting some of the load on the servers from this.