XF 2.0 My INTERNAL_DATA folder has increased from 31GB to 150GB due to duplicate attached files

UMILE

Member
Good Sunday and good afternoon to everyone
A few months ago I needed to update the Xenforo 2.0 version to version 2.2. I saved the whole forum including the internal_data folder. Everything went well but I discovered that the internal_data folder has become very heavy about 150GB I checked XF_ATTACHMENT_DATA in my SQL database but everything is ok. But I still did another test and I realized that a file I have 6 copies. The file_hash is repeated several times in some internal_data folders. For example
In the picture I show you the problemtest.webp
sharp.webp
I returned to use version 2.0 but I would like to clean up the internal_date folder from the access files. Can you recommend an addon or how to automatically delete all excess files?

TNKs everyone
 
Solution
As I say, you will need to restore the files from a backup.

If you didn't make a backup of the files then you may have to do it manually. I don't know if an add-on exists. If one doesn't then you may have to commission a developer to create the add-on for you.

If a developer were to do this for you, the simplest way to do it would be to write a script that goes through each xf_attachment_data record, finds the correct corresponding file inside internal_data/attachments and then move it to a separate folder, say, internal_data_new/attachments.

Once the process is finished, delete internal_data/attachments and then move internal_data_new/attachments to internal_data/attachments.

That should then give you a canonical version of only...
An upgrade from XF 2.0 to XF 2.2 would not cause duplicate attachments. It's not really clear what your exact process was but it very likely was not the recommended nor supported process.

It's also not really clear how you have "returned to use 2.0" because downgrading is also not recommended nor supported.

If I had to hazard a guess you perhaps did a XF to XF import but the source and destination directories for the attachments were the same. To have six duplicates, it's possible you completed this process multiple times and depending on the process you took to revert back to 2.0 you perhaps did the same thing a final time when moving back.

My only feasible recommendation to revert this is to fully restore the files and database from a backup taken before the upgrade.

You can then complete the upgrade process in the correct way as documented in the manual:
 
Surely it happened as you say,. How can I clean up the internal folder_date from the replicated files? Make it manually is really unthinkable. The MySQL file is restored perfectly but the files replicated inside the internal_data folder are present. There is an addon that crosses the data from mysql xf_attachment_data and the internal_data folder gives me the opportunity to clean it in a short time?
 
Last edited:
As I say, you will need to restore the files from a backup.

If you didn't make a backup of the files then you may have to do it manually. I don't know if an add-on exists. If one doesn't then you may have to commission a developer to create the add-on for you.

If a developer were to do this for you, the simplest way to do it would be to write a script that goes through each xf_attachment_data record, finds the correct corresponding file inside internal_data/attachments and then move it to a separate folder, say, internal_data_new/attachments.

Once the process is finished, delete internal_data/attachments and then move internal_data_new/attachments to internal_data/attachments.

That should then give you a canonical version of only the correct attachment files in the right place.

For good measure you may want to delete the data/attachments directory (where thumbnails are stored) and then rebuild thumbnails from Admin > Tools > Rebuild caches > Attachment thumbnails as you may have duplicates in there too.
 
Solution
If a developer were to do this for you, the simplest way to do it would be to write a script that goes through each xf_attachment_data record, finds the correct corresponding file inside internal_data/attachments and then move it to a separate folder, say, internal_data_new/attachments.

wonderful idea!
tnks dear
 
Back
Top Bottom