Project

General

Profile

Actions

Feature #59312

open

No possibility to remove missing indexed files from DB

Added by Robert Vock about 10 years ago. Updated 10 months ago.

Status:
Under Review
Priority:
Should have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
-
Start date:
2014-06-03
Due date:
% Done:

0%

Estimated time:
PHP Version:
7.4
Tags:
Complexity:
easy
Sprint Focus:

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.


Related issues 2 (0 open2 closed)

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

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

Actions
Actions #1

Updated by Frans Saris about 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.

Actions #2

Updated by Marcin Sągol about 10 years ago

+1 for some solution for this issue.

Actions #3

Updated by Wolfgang Wagner almost 10 years ago

This would be a nice feature indeed!

Actions #4

Updated by Armin Vieweg over 9 years ago

+1

Actions #5

Updated by Frans Saris over 9 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.

Actions #6

Updated by Ingo Schmitt over 9 years ago

  • Complexity set to hard
Actions #7

Updated by Benni Mack about 9 years ago

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

Updated by Susanne Moog about 9 years ago

  • Sprint Focus deleted (On Location Sprint)
Actions #9

Updated by Susanne Moog almost 9 years ago

  • Target version changed from 7.4 (Backend) to 7.5
Actions #10

Updated by Benni Mack almost 9 years ago

  • Target version deleted (7.5)
Actions #11

Updated by Clemens Riccabona almost 8 years ago

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

Actions #12

Updated by Frank Gerards almost 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 ...

Actions #13

Updated by Markus Klein almost 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.

Actions #14

Updated by Jörg Wagner almost 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.

Actions #15

Updated by Philipp Gampe over 7 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)
Actions #16

Updated by Jörg Wagner over 7 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

Actions #17

Updated by Viktor Livakivskyi over 7 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.

Actions #18

Updated by Philipp Gampe over 7 years ago

@Viktor sounds like another bug

Actions #20

Updated by Leonie Philine over 5 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?

Actions #21

Updated by Susanne Moog over 5 years ago

  • Tracker changed from Task to Feature
Actions #22

Updated by Michael Bakonyi almost 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 :)

Actions #23

Updated by Jonas Eberle over 3 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.

Actions #24

Updated by Moritz Ahl over 3 years ago

+1. Willing to sponsor.

Actions #25

Updated by Sybille Peters over 1 year 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.

Actions #26

Updated by Philipp Gampe over 1 year 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

Actions #27

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

Actions #28

Updated by Tung Ngo 10 months 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

Actions #29

Updated by Gerrit Code Review 10 months 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

Actions #30

Updated by Gerrit Code Review 10 months 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

Actions #31

Updated by Gerrit Code Review 10 months 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

Actions #32

Updated by Gerrit Code Review 10 months 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

Actions #33

Updated by Gerrit Code Review 10 months 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

Actions #34

Updated by Gerrit Code Review 10 months 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

Actions #35

Updated by Gerrit Code Review 10 months 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

Actions #36

Updated by Gerrit Code Review 10 months 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

Actions #37

Updated by Falko Trojahn 10 months 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!

Actions

Also available in: Atom PDF