Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Please better address a file overwrite situation, ie. where a file is replaced with another of identical name. This may mean two scenarios:
- a file is deliberately uploaded via UI to replace an older one - like when you do some additional processing in Photoshop and what to update the image
- a file is uploaded via UI, but is accidentally named as an already existing one in the target location
Both scenarios deserve special dedicated handling:
- for a mindful replace: we should flush all the styles, or if possible - remove instances of the given file name only. This does not seem to be the case at present
- for an accidental overwrite hazard: we should reveal a warning div in the dialog to present the existing file thumbnail and its usage summary, the div should allow a choice between: (Y) Yes, replace, relink, and flush styles (N) No, don't replace, let me enter a different name for that file
Comments
Comment #1
Dave ReidThis contradicts what is in http://drupalcode.org/project/file_entity.git/blob/86580fef8c3706e3fe378.... We have code that runs image_path_flush() whenever an image file is updated (which happens during replacement).
Could you detail or explain more about how there is an accidental overwrite hazard to begin with? Drupal by default if you are trying to save/upload a file that has the same name as an existing file, will rename it with a suffix (existing_file.pdf -> existing_file_01.pdf). To overwrite a specific file, it has to be a very deliberate action when editing that existing file itself.
Moving this ticket to file_entity where the actual file replacement functionality exists.
Comment #2
moniuch CreditAttribution: moniuch commentedI'm only talking about what I experience - stubborn image referencing beyond my control after I update the file.
Yes, I know, and - frankly - I hate this behavior, and consider the _## files to be system garbage. Even if the mechanism is documented and clear, it makes the folders cluttered and messy. I think it'd be just cleaner if upon upload the system signalled that a file named "file.jpg" already exists at target location, so that I can take my own action: rename the file on my desktop, or be offered an edit field to do that in Drupal. That would be the most deliberate behavior if we talk these terms. Currently, Drupal acts silently.
An ideal would be to offer a system-wide config setting that controls the behavior. I would opt for full control on my side, others could opt for full control on Drupal's side.
I realize this might not be the highest priority at this moment, but I just felt like letting you know how I'd see a nice environment to co-operate with me.
Comment #3
Dave ReidWell the first part is likely your browser, which has a cache of the image. When we truly do an image replacement, nothing we do on the server level matters if the browser still has a cached version of the image. We filed #1701924: Add a cache-busting string to images to try and fix it but it has proven very difficult to actually implement given core's restraints on outputting images. #1979996: Replacing a file does not expire file URL in Varnish is also possibly related to the first part.
So let's narrow this down to the second part only. It seems like a good idea in theory so at this point it needs some mockups or code to move it further for consideration.