Feature #59312
openNo possibility to remove missing indexed files from DB
0%
Description
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 over 10 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 Wolfgang Wagner over 10 years ago
This would be a nice feature indeed!
Updated by Frans Saris almost 10 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 Benni Mack over 9 years ago
- Target version changed from 7.1 (Cleanup) to 7.4 (Backend)
Updated by Susanne Moog over 9 years ago
- Sprint Focus deleted (
On Location Sprint)
Updated by Susanne Moog over 9 years ago
- Target version changed from 7.4 (Backend) to 7.5
Updated by Clemens Riccabona over 8 years ago
Upvote.
It is getting more and more anoying ...
Updated by Frank Gerards over 8 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:
Upvote.
It is getting more and more anoying ...
Updated by Markus Klein over 8 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 8 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 8 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 8 years ago
Steffen Müller has written a TYPO3 scheduler task class that does exactly what Philipp Gampe is proposing:
https://gist.github.com/stmllr/da259f62428cb0b499c48fbaedc932e3
Updated by Viktor Livakivskyi about 8 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 almost 6 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 6 years ago
- Tracker changed from Task to Feature
Updated by Michael Bakonyi over 4 years 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 4 years 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 Sybille Peters almost 2 years ago
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.
Updated by Philipp Gampe almost 2 years ago
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
Updated by Clemens Riccabona over 1 year ago
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 ...).
Updated by Tung Ngo about 1 year ago
- PHP Version changed from 7.2 to 7.4
I have created a patch to tackle this problem, feedback appreciated: https://review.typo3.org/c/Packages/TYPO3.CMS/+/80984
Updated by Gerrit Code Review about 1 year ago
- Status changed from Accepted to Under Review
Patch set 4 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
Updated by Gerrit Code Review about 1 year ago
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
Updated by Gerrit Code Review about 1 year ago
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
Updated by Gerrit Code Review about 1 year ago
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
Updated by Gerrit Code Review about 1 year ago
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
Updated by Gerrit Code Review about 1 year ago
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
Updated by Gerrit Code Review about 1 year ago
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
Updated by Gerrit Code Review about 1 year ago
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
Updated by Falko Trojahn about 1 year ago
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!