Same file name in restore file causes failure

I run into smiliar problem, I tried to migrate the site to local, the database name and admin names, passwords are different, and get this the following error:

Notice: Undefined index: files in theme_backup_migrate_file_list() (line 954 of /var/www/html/sites/all/modules/backup_migrate/backup_migrate.module).
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'temporary://yaoNyou-2015-01-27T07-01-07.mysql_0.gz' 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] => yaoNyou-2015-01-27T07-01-07.mysql.gz [:db_insert_placeholder_2] => temporary://yaoNyou-2015-01-27T07-01-07.mysql_0.gz [:db_insert_placeholder_3] => application/octet-stream [:db_insert_placeholder_4] => 999379 [:db_insert_placeholder_5] => 0 [:db_insert_placeholder_6] => 1422419862 ) in drupal_write_record() (line 7239 of /var/www/html/includes/common.inc).

Warning message

I tried dev version, still the same.

Is this still an issue with 7.x-3.2?

Closing after more than two weeks with no activity.

This is still an issue. Try to reproduce it as follows:

1. Backup entire site as tar.gz
2. Set your post_max_size and upload_max_size to 2MB within php.ini file
3. Try to restore entire site by usint file from #1 above
4. Set your post_max_size and upload_max_size to 360MB within php.ini file
5. Try to restore entire site by usint file from #1 above

A quick workaround is to check your file_managed table manually and delete the most recent duplicates right at the very end of the table and try again with the step #5 from above. This is not a permanent fix, therefore the error should be prevented within the module.

I can neither reproduce the original issue nor #1 with the instructions provided in #4.

I have tried both the literal instructions and the steps that I believe #4 intended to post.

I have some questions / remarks:

- Assuming the intention of choosing 2MB and 360MB was to have one value that was too small to upload the back-up file and one value that was large enough:

Choosing 100KB as a value for the lower end on my system - which is a smaller size than the size of my back-up file, however, led to B&M doing nothing, not even producing an error message or a warning. The PHP log contained the following warning afterwards: [08-Aug-2019 12:13:41 Europe/Berlin] PHP Warning: POST Content-Length of 148383 bytes exceeds the limit of 102400 bytes in Unknown on line 0

- What is upload_max_size supposed to do? The PHP manual does not list this as a directive: https://www.php.net/manual/en/ini.core.php. A similar sounding upload_max_filesize exists, however.

- Why 2MB and 360MB?

- Presumably you have to restart the web server after changing the php.ini values?

- What browser are you using?

- What happens if you select the advanced option "Drop all tables before import (MySQL only)" (assuming you are using MySQL or MariaDB)?

- Do you restore from an uploaded file or from a saved backup?

- Could you post the error message you are getting?

- I thought the problem might be that B&M is attempting to overwrite a half-finished previous restore. I thought I might emulate this behaviour by clicking the "Restore now" button in rapid succession. That does lead to all kinds of error messages (all of the type "Base table or view not found" or "Base table or view already exists"), but in the end B&M does restore the database. (The Drupal log contains only one entry, "Default Database restored from Upload file...", timed to the minute I executed the restore.)

- One thing I noticed in #1 is that the file_managed table there appears to contain a back-up file. I don't know if that means anything. When I look in my file_managed tables, it contains no back-up files.

@BrankoC:

> Why 2MB and 360MB?

I tried to recreate a condition when in the first try you have a tarball way bigger than 2MB and therefore (due to php.ini settings) the information reg. such transfer shouldn't even touch the database, since it will obviously fail. Afterward, you give your server enough of space to upload a file with a different setting and then you try to restore the site again - then boom - you have a duplicate reference within file_managed that causes this issue. I'm quite puzzled that you can't reproduce it though.

> Presumably you have to restart the web server after changing the php.ini values?
Of course.

> What browser are you using?
Chromium: v76.0.3809.87 (Official Build) Manjaro Linux (64-bit)

> What happens if you select the advanced option "Drop all tables before import (MySQL only)" (assuming you are using MySQL or MariaDB)?
Will try it next time when I'll find some more time for this.
MySQL version: 5.5.5-10.4.6-MariaDB

> Do you restore from an uploaded file or from a saved backup?
A file saved from backup.

> Could you post the error message you are getting?
The error message is stated at the very end of the original post.

Thanks for your answers, this is very helpful.

Since I am unable to reproduce the problem, let's hope others have the time to look at this.