No possibility to remove missing indexed files from DB
There currently is no possibility to remove indexed files from DB, when they are missing.
The FileStorageIndexingTask marks the files as missing and the FalStatus-Report shows which files are missing. This report tells the user to restore the files and rerun the indexer to clear the flag.
This means it is not possible to delete files using FTP or otherwise the entries in the DB won't be cleared. It would be nice if the Indexer could be configured to delete missing files in the database, instead of only marking them as missing.
But I can imagine that it gets quite complicated, if the files are still in use somewhere and were deleted using FTP or some other direct access.
Updated by Frans Saris about 7 years ago
- Status changed from New to Accepted
- Priority changed from Could have to Should have
Indeed something we need to add. Maybe something we can add to System -> DB check and can link to from reports module.
And then some overview of all missing files and where they are linked + the possibility to remove some you have selected or all.
Updated by Frans Saris over 6 years ago
- Tracker changed from Feature to Task
- Target version set to 7.1 (Cleanup)
- TYPO3 Version set to 6.2
- Sprint Focus set to On Location Sprint
A new BE (sub) module needs to be created where a admin can view a list of all missing files with the posibility to remove all/only some records from database.
Updated by Frank Gerards almost 5 years ago
It is indeed a dearly missing feature, which shouldnt be that hard to implement.
I would see this as a flag in the scheduler Task for updating the file reference index as this is the point,
where u are sure the "missing" state is most accurate.
Anyways you could check for file_exists before deleting the "missing" DB entries.
Clemens Riccabona wrote:
It is getting more and more anoying ...
Updated by Jörg Wagner almost 5 years ago
Markus Klein wrote:
Keep in mind that you have to do a bit more when cleaning this.
You have to remove all references to that very file as well.
Not really. The major problem are files that are NOT referenced but still listed by the indexer als missing.
Any file that the indexer has seen in his lifetime will create an error when it is removed from the file system using FTP or shell access – even if there is no references at all!
Referenced files that are deleted can be considered operator errors and the request to bring them back is correct.
But I would be happy to have an option to remove the error messages for unreferenced files.
IMHO the indexer records for these files could even be removed without further notice.
Updated by Jörg Wagner almost 5 years ago
Steffen Müller has written a TYPO3 scheduler task class that does exactly what Philipp Gampe is proposing:
Updated by Viktor Livakivskyi almost 5 years ago
I think, it would also make sense to run same query in Fileadmin garbage collection scheduler task, because after a while the Files flagged as missing report is filled with tons of un-useful
/_recycler_/* entries. It makes impossible to see if there are really some problems with missing files, because of such spam entries.
Updated by Leonie Philine Bitto over 2 years ago
- TYPO3 Version changed from 6.2 to 9
- PHP Version set to 7.2
- Complexity changed from hard to easy
This is still an issue in TYPO3 9.
Could https://gist.github.com/stmllr/da259f62428cb0b499c48fbaedc932e3 be included in the core?
Updated by Michael Bakonyi 12 months ago
Having 9.5 installed after running the SQL-command provided by Philipp in my case leads to an error when trying to run the Console command "cleanup:missingrelations" afterwards. Error said something like "Missing record with UID XYZ". After restoring a DB-backup the command doesn't show an error anymore. So some things seem to have changed regarding relation-handling within the last 4 years. Not surprising I guess :)
Updated by Jonas Eberle 8 months ago
@Michael Bakonyi I think this is to be expected if the `sys_file` got deleted.
A `cleanup:missingrelation` afterwards can remove the dangling references. If not, you can end up having to check in Fluid if `file.originalResource` is actually not null. That is not nice.
If you are sure that you are not going to restore these files, this should not lose you anything.
I think we should have a clear documentation how to get the reference index, lost files and file references into a 100% clean state.