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

JacobSingh’s picture

Title: PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry » When uploading a file which existed previously on the file system, fatal primary key violation
Project: Rotating Banner » D7 Media
Version: 7.x-1.0-beta1 » 7.x-1.x-dev
Component: User interface » Code
JacobSingh’s picture

Priority: Normal » Minor

I'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?

aaron’s picture

it sounds like a core issue to me

aaron’s picture

Project: D7 Media » Drupal core
Version: 7.x-1.x-dev » 7.x-dev
Component: Code » file system

yes, it's a core issue -- happens w/ file & image fields w/o media module as well.

arthurf’s picture

Project: Drupal core » D7 Media
Version: 7.x-dev » 7.x-1.x-dev
Component: file system » Code
Status: Active » Closed (works as designed)

When 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.

delalis’s picture

If 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.

je1’s picture

Where will you call file_unmanaged_save_data from in this case?

I need to upload files without database involved in D7.34.

r3z0nate’s picture

I'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?