Have you tried clearing your browser cache?

ImageSharp uses a default browser cache of 14 days (from memory), so even when evicted from the Media Cache (which would happen automatically if the item is deleted from the media library), the browser will still cache the image for a period of time.

ImageSharp also evaluates based on last modified dates, but when using blob storage this translates into the date it was uploaded into blob storage (when not using blob storage, this can be an issue, if you are just renaming files to test with, as the last modified date doesn't change during a rename)

We also have cache busting support for images (you can apply this to the front end)

But we don't yet have that the admin area.

Here's the original issue for this #3925

I did open a pr but it never got merged, so I closed it.

Perhaps it should be a setting for the media app?

Rather than on by default (which the pr did)

No I haven't tried clearing browser cache. That def seems like a pain. Out of curiosity is there a reason not to reopen the PR?

It's a pretty simple PR, probably just need to get the design requirements correct, though i know Sebastien was concerned about the performance implications.
(Note they are memory cached after the first request)

Requirements request:

Do we want default media cache busting as a setting?

This would be then applied to the admin thumbnails, and the asset_url helpers

Personally I think that would be a good addition assuming I'm not missing some other reason it hasn't been implemented yet. And the memory caching makes sense. If we could clear that specific cached item I think that would be fantastic.

@devlife have you verified this was browser cache related?

@deanmarcussen sorry I didn't realize you were waiting for me to verify. I will do so this week.

I've experienced this issue when using the Media Gallery directly. Though when I'm using a "Media Attached Field" I never get this issue because of the fact that when we upload a new file it generates a new uid for it everytime. So if I delete one file on the Media field and reupload the same file it won't use the same name.ext.

Now if you upload a file directly with the media gallery that has the same name than the previous one in a folder. You will get this issue because it will try to get that file from the ms-cache folder without overwriting the one that is in that cache.

Can we try to implement the cache with the FileInfo modified time? This doesn't require FileWatcher

If it is possible to make it work without a file watcher we could then have a site setting to control this behaviour by default

Hmm, as i understand we would have to grab the file info, at least periodically, to see maybe first if the file still

From your other comment @jtkech

So the thinking from Seb was to not cache the file info at all, but do a lookup for for the fileinfo, rather than from the cache, and use the ModifiedDate for the version, rather the hash as we are currently.

I'm thinking this is for media, and static files that are in the tenant file provider, but still for embedded resources, that cannot change, we could continue to use the static cache.

I also need to take a look, and remember all that we did back then...

@deanmarcussen

Okay cool, so it seems that i understood it quite correctly ;) when i said in my related comment in your other PR

... Or if it is fast enough (which is the case for embedded files) maybe grab this file info each time we generate an url, if so maybe we could just append something re-computed from this modified time (if it has changed) in place of doing a hash on the whole file ...

I'm thinking this is for media, and static files that are in the tenant file provider, but still for embedded resources, that cannot change, we could continue to use the static cache.

Okay. Hmm maybe also for embedded files, currently if you change some file contents and redeploy your app the appended version based on the content hash will change to bust e.g. browser caches, but it would be the same by using the modified time that here is the last modified time of the module assembly file.

@jtkech

... Or if it is fast enough (which is the case for embedded files) maybe grab this file info each time we generate an url, if so maybe we could just append something re-computed from this modified time (if it has changed) in place of doing a hash on the whole file ...

20% slower to drop the cache. I think I will look to a cache expiry option (configurable), that will drop it after 5 minutes, and some events (like tag:cache) to drop it faster. Covers both bases, without the performance overhead. And not a full hash, just a date entry (because if it's calculating every 5 minutes that's still expensive)

@deanmarcussen

Sorry didn't have any time as i had to fix #9188 but yes looks like a good way to go.

What i can say is that around distributed things, for me there are 2 remaining and important areas where we need to work on, Lucene indexes and Media cache, we talked about it recently with @Skrypt, we ended up that the first "work" would be to define, as it is possible, what we really want, good progress ;) e.g. does Lucene should work with multiple instances on the same file system, or just forget it, and so on, and then try to find the best compromise.

About extending Media cached files management, maybe we could open a new issue to start working on it, i think it is important and i will work on it too, maybe not immediately as i planned to look at AuditTrail this week end.

Hi,
the problem discussed in this thread must also be considered with the use of a web farm. If you update a file in the Media Gallery with the same name, it is updated in the media cache of the responding server but remains unchanged in the cache of the other servers in the web farm. Is there a solution to this problem?

Thanks

Is there an update on this?

When I try to replace a file in media library, I'm getting the following error:

"Error: Cannot create file '_branding/tenant-logo.png' because it already exists."

Is there any solution for the cache problem, when deleting a file and then uploading a different file with the same name (so the website links will still be valid?

This ticket is still open since 2020? Anything new to that? Switched to a new issue, as suggested by @jtkech ?

Nothing that we agreed on so far. But yes, I agree that it should be a prioritary issue to resolve.

Has any solution been found to this issue?

I am attempting to upload new versions of files with the same name but get the warning "Cannot create file..already exists".

I would like to be able to accept the warning and upload anyway.

I can delete the old file and update with the newer version but this is cumbersome and this issue seems to have been around for a while. Any ideas?

Thanks in advance

I will address this one, we could add an option to overwrite the media but I might need a help from those who working on Azure or S3 storage