Task #57545
closed
Missing metadata entry impossible to regenerate.
0%
Description
While finding the ground issue behind #46020 we came to the point that it is impossible to generate sys_file_metadata entries if they are missing for a file.
The tables sys_file and sys_file_metadata have a 1:1 relation, if the metadata is missing for a file in sys_file an empty record is inserted into sys_file_metadata which won't be updated with metadata afterwards. This leads to the issue that images will be outputed as width/height=0
We need the possibility to update such data.
What happens in the situation was described in http://forge.typo3.org/issues/46020#note-74
Updated by Alexander Opitz about 10 years ago
- Category set to File Abstraction Layer (FAL)
Updated by Frans Saris almost 10 years ago
Could you try as workaround the following steps:
- Set missing flag for all files in your local storage(s)
UPDATE sys_file SET missing = 1 WHERE storage = 1; - Run the "File Abstraction Layer: Update storage index (scheduler)" for all your local storages
The indexer will find the missing files and re-indexes them before the missing flag is reset.
In the indexer has some basic functionality to find image dimensions for files in local storages so when re-indexed the width and height are fetched and set again for the images.
Updated by Alexander Opitz almost 10 years ago
While Running the task I get:
Execution of task "File Abstraction Layer: Update storage index (scheduler)" failed with the following message: Task failed to execute successfully.
Class: TYPO3\CMS\Scheduler\Task\FileStorageIndexingTask, UID: 1
Nothing written in any log file.
Updated by Alexander Opitz almost 10 years ago
Debugged it to show the exception:
RecursiveDirectoryIterator::__construct(/.../typo3-master/fileadmin/a): failed to open dir: Permission denied
Uncool the indexer falls about the same stuff we fixed for the tree.
Updated by Alexander Opitz almost 10 years ago
BTW. We shouldn't catch the Exception, the Scheduler handles Exception themselves. Removing the catch would bring following message:
Execution of task "File Abstraction Layer: Update storage index (scheduler)" failed with the following message: RecursiveDirectoryIterator::__construct(/.../typo3-master/fileadmin/a): failed to open dir: Permission denied
Not nice but it tells more to the user.
Updated by Sybille Peters over 9 years ago
Alexander, perhaps you could make a new issue out of your last comment. Issue still exists in 6.2.6, leading to error message without any details in FAL indexer and no info whatsoever in logs. Passing the original exception should be somewhat comparatively easy to fix, I suppose.
Updated by Fabien Udriot about 9 years ago
- Status changed from Accepted to Resolved
We can close this ticket, following the resolution of #62829.
Updated by