Project

General

Profile

Actions

Bug #102302

closed

sys_file_processed entries overwritten with null values

Added by Mordamir about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Extbase
Target version:
-
Start date:
2023-11-01
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
11
PHP Version:
8.1
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

After Upgrading typo3 to version 11.5 we got a problem with processed images. The processed images was all cleared after the update.
But after some time we found many database entries in sys_file_processedfile with identifier set to empty and name to null. After reading some other issues this is the normalbehaviour for images which dont need processing. But in our case its a little bit different: The images are first processed normally with correct entries to sys_file_processedfile and later overwriten with the empty values.

example sys_file_processedfile:

                        uid     tstamp      crdate      storage    original identifier                                              name                                configuration configurationsha1                     originalfilesha1                               task_type           checksum     width     height     processing_url
after first processing: 711344     1698676626     1698676626     1     10113     /_processed_/b/8/csm_2019-07-16_Salbei_1_1c6cce4b4...     csm_2019-07-16_Salbei_1_1c6cce4b48.jpg     [BLOB - 174 B]     e68b0574e8909d6bdf9714bb2b6d79f791a1494e     89d18842cc172696606416e426948cae08bf130d     Image.CropScaleMask     1c6cce4b48     1080     1920     NULL
after some time:        711344     1698682465     1618402081     1     10113         NULL     [BLOB - 174 B]     e68b0574e8909d6bdf9714bb2b6d79f791a1494e     89d18842cc172696606416e426948cae08bf130d     Image.CropScaleMask     1c6cce4b48     1080     1920     

Most values are the same, only tstamp, crdate, identifier, name and processing_url are changed. Looking up the access log at the tstamp-value i did not find suspect access. The timestamp also does not appear the be the time the zeroing happens, because this is 2 days older then change happens to the page with the image.

The question for me is how its possible that an already processed image (db entry) gets overwritten? The processed image itself does not get deleted, but will not be used anymore, because the db says there is no processed image.
And second, how can i find the cause?

Actions

Also available in: Atom PDF