File indexing: Emit signal when file marked as missing?
It might be helpful to emit a signal when
TYPO3\CMS\Core\Resource\Index\Indexer::detectMissingFiles() finds a file is missing.
Any extension that adds capabilities concering file management might want to know about that.
This could be added at
TYPO3\CMS\Core\Resource\Index\FileIndexRepository::markFileAsMissing() and simply pass the
$fileUid from that function.
[FEATURE] Emit Signal when an IndexRecord is marked as missing
Introduce a new signal that is emitted when the FAL indexer encounters
a sys_file record which does not have a corresponding filesystem entry
and marks it as missing.
Reviewed-by: Christian Kuhn <email@example.com>
Tested-by: Christian Kuhn <firstname.lastname@example.org>
Reviewed-by: Frank Nägler <email@example.com>
Tested-by: Frank Nägler <firstname.lastname@example.org>
#3 Updated by Christian Reiter over 4 years ago
- Add a listener that just writes to devlog
- Ensure FAL index is clean and up-to-date in a local test system
- Remove a file from fileadmin/ by manual action outside TYPO3 (Explorer, shell...)
- Run the task "File Abstraction Layer: Update storage index (scheduler)"
- Check devlog - entry should show up.
About centralizing "markAsMisssing" function:
There is an "on the fly" adding to index occuring when a folder is viewed in the File > List module. Any file created there from outside TYPO3 is newly added to the index.
However the other index actions, such as "markAsMissing" or updating on change, do not seem to be fired in this situation. They only occur on scheduler run.
#5 Updated by Christian Reiter over 4 years ago
what can I do to get the patch reviewed?
FileIndexRepository emits the suggested signal "recordMarkedAsMissing" , a listener can check whether a different sys_file has a record with the same SHA1 as the missing one and possibly repair references.
Vice versa, when
FileIndexRepository emits the existing signal "recordCreated" the listener can check whether the newly added record has the same SHA1 as something that was previously marked missing.
When an external rename/move takes place, which case occurs depends on whether the indexer comes across the "missing" or "added" file first.
Capturing both ensures that any rename/move which does not simultaneously change the content can be "rescued" in terms of fixing references as well as avoiding record duplication, if an extension listening to the signals wants to do that.