U4-11000 - Incorrect filenaming when replacing media with third party file system provider

Created by Roy van den Ekker 21 Feb 2018, 10:00:08 Updated by Roy van den Ekker 22 Feb 2018, 13:19:11

Duplicates: U4-8949

Relates to: U4-7828

Relates to: U4-8949

Relates to: U4-10624

When using an third party file system provider instead of using the default PhysicalFileSystem configuration, I am having problems with the ID used in the media library (either as folder name or filename depending on the UploadAllowDirectories setting). When I replace a file each new version is uploaded with a new ID instead of keeping the old one. This prevents me from using the URL (www.host.com/media/id/image.png hardcoded in HTML. Each upload increments the integer while using default PhysicalFileSystem correctly replaces the existing image with a new version.

Able to reproduce with blank Visual Studio web project.

  • Use NuGet packages for UmbracoCMS and UmbracoFileSystemProviders.Azure.-
  • Default configuration, local emulated blob storage or actual Azure storage.
  • Works fine with Umbraco 7.5.14 and UmbracoFileSystemProviders.Azure 1.0.2.
  • Works incorrect starting Umbraco 7.6 with UmbracoFileSystemProviders.Azure 1.0.2.

Comments

Sebastiaan Janssen 21 Feb 2018, 12:42:13

This is the expected behavior in Umbraco (not saying it's great behavior, but it's "normal" and isn't caused by the file system provider).

The discussion in U4-8949 has some workarounds in it to try.


Roy van den Ekker 21 Feb 2018, 12:57:26

@sebastiaan If I may ask (hope this doesn't reopen anything), why does the default setup (PhysicalFileSystem) not behave like that? It keeps the numbering intact.


Sebastiaan Janssen 21 Feb 2018, 13:19:45

Okay, reading this again, I am unsure what the problem is. You say "Each upload increments the integer while using default PhysicalFileSystem correctly replaces the existing image with a new version."

So it works in Umbraco default but not when this FileSystemProvider is used?


Roy van den Ekker 21 Feb 2018, 13:27:31

Default setup:

  • Upload new image called 1.png in media library. Link to media becomes (intial value) "/media/1001/1.png".
  • Edit image or something, replace existing 1.png. Link to media stays "/media/1001/1.png".

Install UmbracoFileSystemProviders.Azure

  • Upload new image called 2.png in media library. Link to media becomes "/media/1002/2.png".
  • Edit image or something, replace existing 2.png. Link to media changes to "/media/1003/2.png".

So 1002 became 1003 and when browsing to the old 1002-location, image is unvailable because removed from storage.

Talked/emailed to the UmbracoFileSystemProviders.Azure developer, his plugin is unchanged since 0.57. He cannot recall any changes which could lead to this and pointed my in your direction.


Sebastiaan Janssen 21 Feb 2018, 13:43:28

Ha! Well, then:

  1. CMS works better than I expected now, U4-8949 might be partially obsolete now
  2. I might have to point you back to them, but it could also be that CMS is doing something different when a FSP is used

To set expectations: we don't have the time to investigate this right now, so if you want to dig into the source and provide more details as to why this happens that would greatly improve the timeframe in which this can be solved. :)


Roy van den Ekker 21 Feb 2018, 13:50:09

No worries. Just the marketeers who have to do some more work right now. I'll see what I can do.

Bedankt.


Roy van den Ekker 22 Feb 2018, 12:42:40

It's not Umbraco. It's a version of the plugin not compatible with latest Umbraco version (it's based on Core 7.1.9 and untested after updates) together with its implementation of GetRelativePath. That one returns "/media" while it should not return that part of the URL. The one in PhysicalFileSystem does it the correct way.

My bad "blaming" the wrong tooling though I get the confusion for the other party too.


Sebastiaan Janssen 22 Feb 2018, 13:15:48

Haha! Oh no, we've all been there. :)

So the newest version of the plugin is all good? I'll close this again unless something else needs looking at.


Roy van den Ekker 22 Feb 2018, 13:19:11

No, plugin is still incorrect. Spent morning debugging plugin and Umbraco after compiling the sources myself. Made my own changes to the plugin code to get it working and mimicking the core implementation.


Priority: Normal

Type: Bug

State: Closed

Assignee:

Difficulty: Normal

Category:

Backwards Compatible: True

Fix Submitted:

Affected versions: 7.6.0, 7.8.1

Due in version:

Sprint:

Story Points:

Cycle: