TYPO3 Core

+1 for some solution for this issue.

This would be a nice feature indeed!

+1

Upvote.
It is getting more and more anoying ...

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:

Upvote.
It is getting more and more anoying ...

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.

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.

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)

Steffen Müller has written a TYPO3 scheduler task class that does exactly what Philipp Gampe is proposing:
https://gist.github.com/stmllr/da259f62428cb0b499c48fbaedc932e3

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.

@Viktor sounds like another bug

@Phillip Kroll, done #78473 :)

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 :)

@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.

+1. Willing to sponsor.

Question: This issue is about removing sys_file entries with missing=1 (where the files have been removed, but not the sys_file entries), right?

How did these occur? Was it by a bug? Were the files manipulated on the file storage level without updating the database entries? Why?

It is my understanding, this (sys_file.missing=1) should not happen, if TYPO3 methods are used. E.g. if you remove a file from the backend, the sys_file entry will also be removed.

I would like to understand this better. Also, I have issues with some of the suggestions and I think problem should be addressed on a deeper level.

Sybille Peters wrote in #note-25:

Question: This issue is about removing sys_file entries with missing=1 (where the files have been removed, but not the sys_file entries), right?

How did these occur? Was it by a bug? Were the files manipulated on the file storage level without updating the database entries? Why?

Correct. The files have been manipulated outside of TYPO3, e.g. via FTP or some automated process.

Also happens if you restore some database dump and you do not have a copy of the filesystem from the same time. Or if you do not want to restore the file system, because you have new files already in it.

It is my understanding, this (sys_file.missing=1) should not happen, if TYPO3 methods are used. E.g. if you remove a file from the backend, the sys_file entry will also be removed.

I would like to understand this better. Also, I have issues with some of the suggestions and I think problem should be addressed on a deeper level.

The underlaying problem is how to get the real filesystem state and the TYPO3 database state back in sync.

Right now, one would have to restore the file to again delete it within TYPO3. It would be much better if there would be a way to clear the warnings from within TYPO3 (.e.g. delete unused missing files).
If the file is still used in a relation, then the problem should be solved by
a) restoring the file or
b) removing the relation and the file entry

So that's true, what Philipp says.

From time to time it happens, that files get deleted outside of TYPO3, via FTP oder SSH.
These files often do not have a relation, and also they do not need to be restored. But happening that every now and than can fill up these warnings.
As Philipp wrote already 6 years ago, you could do this directly on the database:

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)

But I do not really like that approach (although I use it, because it's the only way to go for now).

BTW: for me it happens more often on really old TYPO3 instances, which got upgraded up to now, starting somewhere back in the 3.5/3.6 era.
Back then we had files in fileadmin on a regular base, which should not be stored there anymore, and sometimes it's nearly impossible to remove them via TYPO3 (eg. some tt_news hook php file, a patched gmenu layers php file etc ...).

Patch set 5 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80984

Patch set 6 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80984

Patch set 7 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80984

Patch set 8 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80984

Patch set 9 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80984

Patch set 10 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80984

Patch set 11 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/80984

Tung Ngo wrote in #note-28:

I have created a patch to tackle this problem, feedback appreciated: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80984

+1 for the patch. Had to try that by backporting to 10.4, though: worked flawlessly for me, much appreciated.

Feature request: could we please have the possibility to index multiple storages at once?

Like --update-storage=1,5,7

Thanx!