Bug #56077
closed
Blocking errors if files deleted
100%
Description
If you delete files on the server (without TYPO3) you can get blocking errors as editor.
My specific case was the thumbnails of tt_news in listview. If the connected image does not exist you get an error ('File xyz does not exist' thrown in LocalDriver) at the whole list-view (instead of a warning). As a limited editor it is almost impossible to fix this error.
I researched and found out that this problem occurs on some places (more or less).
I use TYPO3 6.2beta5.
I'am not sure if it is related to FAL, but i think it is no tt_news-problem.
To reproduce: Create news and link image (i uploaded it initially). Then i used an regular editor backend user. In list view i got this error.
Updated by Thomas Sperling about 10 years ago
I forgott: For reproducing, you have to delete the file of course.
Updated by Frans Saris about 10 years ago
- Status changed from New to Needs Feedback
For this we added the missing flag feature that is set by the file indexer schedular task.
If you (re)move files direct on filesystem it is recomended to have thuis schedular task run once in a while.
Could you try that and when it still rails post the exception here?
Updated by Markus Klein about 10 years ago
@Frans: Ok, but this is IMO no solution.
What if some person deletes a file and the index regenerated 3 hours later?
In the meantime the BE (and probably other places) is broken.
As a user I'd expect graceful degradation, like a warning somewhere.
Updated by Markus Klein about 10 years ago
- Status changed from Needs Feedback to Accepted
Updated by Frans Saris about 10 years ago
Markus,
During some testing I found out that the missing flag isn't the solution here. So I agree with you that this should be fix.
Gr. Frans
Updated by Steffen Ritter about 10 years ago
@Markus: that is a solution - if you allow anybody (your server, your editor, ftp -whatever) to manage files OUTSIDE the TYPO3 file module you are obligated to have the indexer task running.
The whole concept of FAL is based on the expectation, that the sys_file table always is sync with the file-system (reliably). This promise needs to be kept.
Everything which goes wrong because this indexer task is not run frequently enough and changes happened outside TYPO3 - it's not a core fault.
If the missing flag at some places is not enough - than we need to improve the usage of that - of course, but not if it even is not flagged as missing.
Updated by Frans Saris about 10 years ago
Problem is that TYPO3\CMS\Backend\Utility\BackendUtility::thumbCode() doesn't catch the exception. Working on a patch for that now.
Updated by Gerrit Code Review about 10 years ago
- Status changed from Accepted to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28284
Updated by Gerrit Code Review about 10 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28284
Updated by Gerrit Code Review about 10 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28284
Updated by Gerrit Code Review about 10 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28284
Updated by Frans Saris about 10 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 5869277c2cb262605ac76c97c6bfe3771fc10fe3.
Updated by