Bug #60703

sys_file indexer and file module throw an exception if a record does not have a physical representation

Added by Nils Blattner over 6 years ago. Updated over 6 years ago.

Must have
File Abstraction Layer (FAL)
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:



When I access a folder in the file module with a sys_file record that has no physical file (it was deleted by ftp, shell etc.), an exception is thrown.

#1319455097: Error while fetching permissions for .....

Setting them "missing" manually in the DB will make the file module ignore that. This should be detected automatically.

Furthermore, when the indexer scheduler task tries to reindex the file, it also throws an exception and thus aborts.
typo3/sysext/core/Classes/Resource/Driver/LocalDriver.php line 270:
if (!file_exists($absoluteFilePath)) {
throw new \InvalidArgumentException('File ' . $fileIdentifier . ' does not exist.', 1314516809);

The indexer should be robust enough to manually mark the missing files or, even better, try to find the file by sha1 hash.

The file module should be at least that robust, since non-administrator see it and the indexer should be even more so, since I do not want to go into the db manually every time a file was deleted by an outside source.
Maybe I'm missing some configuration option that does exactly that. If that is the case please point me to it and consider enabling it by default.

Thanks in advance!


Updated by Frans Saris over 6 years ago

  • Status changed from New to Needs Feedback

When you change your files outside of TYPO3 it's recommended to have the FAL indexer task running every x minutes.
Files that are added will get indexed and files that got removed will be marked as missing.

I also recommend to use TYPO3 functionality as much as possible to add, edit, move and delete files. Thus to make sure all references stay up to date and to prevent that a used (referenced) file is deleted.

When exactly do you run into the exception? Because the indexer only handles files that are physical present. Could it be that while the indexer was running a file got deleted from the storage?


Updated by Nils Blattner over 6 years ago

Hi Frans

The indexer task is set up, but fails on the first missing file as outlined in my original post with an InvalidArgumentException.
I agree that using the backend functionality is the preferred method, but it mustn't be that file deletion from the outside breaks the indexer completely and prevents folder access in the backend.



Updated by Alexander Opitz over 6 years ago

Which TYPO3 6.2 version do you use?


Updated by Nils Blattner over 6 years ago

That was 6.2.3.

Apparently 6.2.4 solved this already.

However I noticed that this creates an extra sys_file record with missing = 1. A really desirable feature would be that this is detected as a move instead.
=> I will create a new feature request for that

Sorry for the inconvenience.


Updated by Alexander Opitz over 6 years ago

  • Status changed from Needs Feedback to Closed

Hi Nils,

thanks for help.

Finding the file by sha1 isn't easy. As out of the nature of the old file handling there may be many duplicates (which should be checked eliminated before but that's no core function or extension yet).

Also available in: Atom PDF