Feature #59312

No possibility to remove missing indexed files from DB

Added by Robert Vock over 7 years ago. Updated 11 months ago.

Should have
File Abstraction Layer (FAL)
Target version:
Start date:
Due date:
% Done:


Estimated time:
PHP Version:
Sprint Focus:


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.

Related issues

Related to TYPO3 Core - Task #50876: Handling of deleted files in FALClosed2013-08-06

Related to TYPO3 Core - Bug #78473: "Fileadmin garbage collection" scheduler task doesn't remove entries from sys_fileClosed2016-10-27


Updated by Frans Saris over 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 Marcin Sągol over 7 years ago

+1 for some solution for this issue.


Updated by Wolfgang Wagner over 7 years ago

This would be a nice feature indeed!


Updated by Armin Vieweg about 7 years ago



Updated by Frans Saris about 7 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 Ingo Schmitt almost 7 years ago

  • Complexity set to hard

Updated by Benni Mack over 6 years ago

  • Target version changed from 7.1 (Cleanup) to 7.4 (Backend)

Updated by Susanne Moog over 6 years ago

  • Sprint Focus deleted (On Location Sprint)

Updated by Susanne Moog over 6 years ago

  • Target version changed from 7.4 (Backend) to 7.5

Updated by Benni Mack over 6 years ago

  • Target version deleted (7.5)

Updated by Clemens Riccabona over 5 years ago

It is getting more and more anoying ...


Updated by Frank Gerards over 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 Markus Klein over 5 years ago

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.


Updated by Jörg Wagner over 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 Philipp Gampe about 5 years ago

Until this is fixed, you can run the following SQL on regular base:

DELETE FROM sys_file
WHERE sys_file.missing=1
AND sys_file.uid NOT IN (SELECT sys_file_reference.uid_local FROM sys_file_reference WHERE sys_file_reference.uid_local=sys_file.uid)

Updated by Jörg Wagner about 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 about 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 Philipp Gampe about 5 years ago

@Viktor sounds like another bug


Updated by Leonie Philine Bitto almost 3 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 Susanne Moog almost 3 years ago

  • Tracker changed from Task to Feature

Updated by Michael Bakonyi over 1 year 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 about 1 year 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.


Updated by Moritz Ahl 11 months ago

+1. Willing to sponsor.

Also available in: Atom PDF