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.Whenever BM lists files in a destination it leaves a load of temporary files, mostly empty. These eventually get cleaned up by cron, but shouldn't be left behind in the first place. If you have a destination with a lot of files, and refresh the list multiple times before cron gets to clean up, you can end up with hundreds of files in /tmp.
It's only one line of code to fix it, patch follows.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | backup_migrate-delete_temp_files-3018853-2.patch | 240 bytes | RickJ |
| |||
Comments
Comment #2
RickJ CreditAttribution: RickJ commentedComment #3
DamienMcKennaThanks for that, RickJ, we'll try to review it soon.
BTW, the "assigned" field is for indicating you're actively working on something, once you've finished the work (or can't continue on it) it's preferred to set it back to "unassigned".
Comment #4
DamienMcKennaAny recommendations for steps to reproduce the problem? Is it a particular destination that creates the temp files?
Comment #5
RickJ CreditAttribution: RickJ commentedI was getting this specifically using AWS S3, but I think I found it with other destinations. It was a while back, I just did a quick fix. I thought it was about time I posted it as a patch!
It occurs when you refresh a remote destination, and it builds a complete new listing. It's largely due to the implementation of the backup_file class - every time an object of this class is instantiated, it creates a temporary file on disk, even if that file is never used. In building the list, especially if it includes .info files, several backup_file objects are created for every file listed, and therefore lots of empty disk files.
You can find them all in /tmp on the host.
Comment #6
DamienMcKennaOk, I was able to where the files were being created during a backup, and saw that there were some empty files that should have been cleaned up, but I think it needs to be narrowed down to trigger after the files are no longer needed.
Comment #7
RickJ CreditAttribution: RickJ commentedThe point where I've put the cleanup is exactly after the files are no longer needed!
All that's happening in the list_files function is that a list of backup filenames is being created, then cached. The process of acquiring the names uses backup_file objects, which creates the temporary files as a by-product. The content of the .info files is read in the call to load_files_info, at which point it's all in memory, enabling it to be cached.
Once the file list is written to cache it's in the same state as if it's been read from cache, neither of which any longer depends on the temporary disk files.
Comment #9
DamienMcKennaThanks RickJ. Committed.