I'm logging this as a potential bug because the way I'm thinking it should work is different than what I'm experiencing and I'd like to understand why it works the way it does, and possibly discuss changing to how I think it should work.
Scenario 1
- Upload a new file to a file or image field.
- Immediately remove the file.
- Re-upload the same file.
Note that the resulting filename in step 1 and 3 are the same, which would indicate that the first file is actually removed from the system and re-uploaded.
Scenario 2
- Upload a new file to a file or image field.
- Save the node.
- Edit the node.
- Remove the file you uploaded in step 1.
- Re-upload the same file.
Note that the resulting filename in step 1 and step 5 are different. Re-uploading the file appends _0
to the filename within the files directory and the original file was never removed from the file system.
Also note that even after a node save in between step 4 and 5, the file that is re-uploaded is renamed and the original never deleted.
Expectation
I would have expected that during step 4 in scenario 2 that the file would be removed from the file system as well as the database and therefor upon re-upload of a file with the same name that the file name not change. Otherwise, how else are files ever deleted?
Recent comments
That function also exists in Backdrop so it might be something else going on. https://github.com/search?q=repo%3Abackdrop%2Fbackdrop%20image_gd_create...
imagecolorsforindex(): Argument #2 ($color) is out of range
I did some searching and learned that this is a known problem with some GIF images. The Drupal 7 api docs show that there is additional code in image_gd_create_tmp.inc to check for this case and...
imagecolorsforindex(): Argument #2 ($color) is out of range
@Coffee70 Thank your for the further clarification. I just wasn't clear if you used the modules in the backdrop-contrib repos or rolled your own through coder_upgrade. With your experience I am...
Customizable newsletter