Hey guys, love the simplicity of the module.
Ran into a little problem, while im working on the banner for the site with filezilla and photoshop.
i had the image file named test.jpg
What happened was that I had uploaded the test.jpg image through the drupal 7 rotating block - configuration. - it works perfectly fine.
I then logged into my filezilla and deleted the test.jpg. Did a bit of editing to my test.jpg image and saved it and tried to re-upload test.jpg through the same method. That was when the below error showed up.
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'temporary://test.jpg' for key 'uri': INSERT INTO {file_managed} (uid, filename, uri, filemime, filesize, status, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => test.jpg [:db_insert_placeholder_2] => temporary://test.jpg [:db_insert_placeholder_3] => image/jpeg [:db_insert_placeholder_4] => 72566 [:db_insert_placeholder_5] => 0 [:db_insert_placeholder_6] => 1300844881 ) in drupal_write_record() (line 6776 of /home/admin/public_html/includes/common.inc).
I had previously noticed that, when I did not delete the test.jpg file, it would allow me to upload the same named image file (test.jpg) and it will be saved as test_0.jpg, test_1.jpg, etc. on the website.
It still works as long as I don't use test.jpg anymore. I could use some other name and still upload the image.
So yea... thought i bright it up, and just wondering if there is anything to be done about it.
Comments
Comment #1
JacobSingh CreditAttribution: JacobSingh commentedComment #2
JacobSingh CreditAttribution: JacobSingh commentedI'm tempted to say this isn't *really* a bug, that it should throw an error because the file_managed table is no longer reflecting reality... What would be a more appropriate way to handle tihs?
Comment #3
aaron CreditAttribution: aaron commentedit sounds like a core issue to me
Comment #4
aaron CreditAttribution: aaron commentedyes, it's a core issue -- happens w/ file & image fields w/o media module as well.
Comment #5
arthurf CreditAttribution: arthurf commentedWhen a file is removed not by Drupal there is little that can be done to prevent this error- the problem occurs because the file being uploaded appears unique in the file system but when it is saved it collides with the existing entry in the DB. Drupal checks the file system not the database when uploading and saving files so there is nothing that Media can really do about this.
I'm closing this as works by design because this is how the standard Drupal file creation works.
Comment #6
delalis CreditAttribution: delalis commentedIf you don't care about the {file_managed} table, you can instead call file_unmanaged_save_data(). This will not even attempt to insert the entry into the {file_managed} table.
Comment #7
je1 CreditAttribution: je1 commentedWhere will you call file_unmanaged_save_data from in this case?
I need to upload files without database involved in D7.34.
Comment #8
r3z0nate CreditAttribution: r3z0nate commentedI'm having the same issues with forms that always allowed users to replace files managed by Drupal in the past, with files that have the same name. It never was an issue, and now I have to remove the ajax upload and create new submit functions.
It's almost as if instead of adding either a confirmation that you are replacing a managed file, or at least an error that says the file is already managed, which is what the makers of upload_qc did, to just throwing an error. What was that thought process?