Bug #44616
closed
Image caching broken for im_noScaleUp = 1
0%
Description
Regarding T3CMS V6.0.0
In the BE first everyting is OK.
The CE Image is all OK, the preview is shown corectly
In FE all is OK, too.
Then I have set im_noScaleUp = 1 in the install tool.
Now, FE and BE are filled up with Errors:
Uncaught TYPO3 Exception
#1329821485: File has been deleted. (More information)
RuntimeException thrown in file
typo3_src-6.0.0/typo3/sysext/core/Classes/Resource/AbstractFile.php in line 492.
9 TYPO3\CMS\Core\Resource\AbstractFile::getPublicUrl(boolean)
typo3_src-6.0.0/typo3/sysext/backend/Classes/Form/Element/InlineElement.php:
00555: unset($imageSetup['field']);
00556: $imageSetup = array_merge(array('width' => 64, 'height' => 64), $imageSetup);
00557: $imageUrl = $fileObject->process(\TYPO3\CMS\Core\Resource\ProcessedFile::CONTEXT_IMAGEPREVIEW, $imageSetup)->getPublicUrl(TRUE);
00558: $thumbnail = '' . htmlspecialchars($recTitle) . '';
00559: } else {
...
In BE and FE I have to click the reload Btton for every Image in the page, and jes, I have up to 1500pics on a single page! Happy Clicking.
All image-cache is broken, a extbase-Extention with lots of pictures have the same problem.
Reloading the page once per image, heples.
Clearing the Cache, even by emptying the cache-table does bot help or deleting the temp-folder.
Updated by Christian Tauscher about 11 years ago
Workaround:
truncate sys_file_processedfile
seems to solve the Problem. Dont know what this will have for side-Effects.
Can this table (even ist a sys-table) deleted from time to time?
Updated by Andreas Wolf about 11 years ago
- Category changed from Caching to File Abstraction Layer (FAL)
- Status changed from New to Accepted
- Assignee set to Andreas Wolf
- Target version set to 6.0.1
Christian Tauscher wrote:
Workaround:
truncate sys_file_processedfile
seems to solve the Problem. Dont know what this will have for side-Effects.
Can this table (even ist a sys-table) deleted from time to time?
Hm, no. This table is only a cache table, but you should not truncate it, otherwise all generated images have to be regenerated, so that's no viable solution for almost all sites.
I guess the problem is that there is no proper detection that the image has not been reprocessed (because of the noscaleup parameter). The point is that a part of the cached image's identifier is a hash of the image processing information. Therefore, setting im_noscaleup does invalidate all cached images. I think that this together with the bug you found completely breaks your FE output.
I'll try to dig into this, but my spare time is really limited currently. However, if you could contact me via Jabber, we can maybe sort this out a lot faster (Jabber ID awolf (at) jabber.ccc.de).
Updated by Andreas Wolf about 11 years ago
- Subject changed from Error thrown by FAL to Image caching broken for im_noScaleUp = 1
Updated by Christian Tauscher about 11 years ago
Sorry, Andreas....
i have no idea how this jabber-dinges work.
I should know about this - many of may cstomers like this Jabber-ICQ-ircchannels, but I never got into this.
What for? I have e-mail and a phone...? Maybe we could communicate throug one of this channels.
Best regards from stone-age ;-)
Christian.
Updated by Camelia M about 11 years ago
I have a similar problem with im_noScaleUp = 1 but it's even weirder. I occasionally get different images in front-end then backend. I assume it's also related to caching because link in frontend leads to a (wrong) 'processed' image.
Updated by Andreas Wolf about 11 years ago
Camelia M wrote:
I have a similar problem with im_noScaleUp = 1 but it's even weirder. I occasionally get different images in front-end then backend. I assume it's also related to caching because link in frontend leads to a (wrong) 'processed' image.
I think your problems could be related to the files having the same filename after being replaced? Could you check #44645 if your situation is similar?
Updated by Camelia M about 11 years ago
Andreas Wolf wrote:
Camelia M wrote:
I have a similar problem with im_noScaleUp = 1 but it's even weirder. I occasionally get different images in front-end then backend. I assume it's also related to caching because link in frontend leads to a (wrong) 'processed' image.
I think your problems could be related to the files having the same filename after being replaced? Could you check #44645 if your situation is similar?
I'm afraid not. My images have different names and the filename in 'processed' folder is built as 'preview_'+original_name+some_unique_code.
But even though file names are not the same, as soon as I make 'im_noScaleUp = 1' images get mixed in a very strange way. (before activating no scale up images are corect, after activating, other images, with other sizes replace the correct ones).
Updated by Camelia M about 11 years ago
It seems I have several files that have originalfilesha1 identical. I think this is not normal. Is it?
Updated by Camelia M about 11 years ago
Camelia M wrote:
It seems I have several files that have originalfilesha1 identical. I think this is not normal. Is it?
And they also point to the same id of sys_file (column original in 'sys_file_processedfile') even tough they have a different name and they are completely different images.
Updated by Andreas Wolf about 11 years ago
Camelia M wrote:
Camelia M wrote:
It seems I have several files that have originalfilesha1 identical. I think this is not normal. Is it?
And they also point to the same id of sys_file (column original in 'sys_file_processedfile') even tough they have a different name and they are completely different images.
This is really weird. Would you mind providing me with a dump of your sys_file, sys_file_processedfile tables? You could send it to me via email so I can analyze it (just drop me a note to andreas.wolf (at) typo3.org).
Updated by Andreas Wolf about 11 years ago
(Crosspost from #45168)
Could anyone of you who experiences this error run the following SQL query and report on the results?
SELECT s.uid, f.storage, s.name AS processedname, s.identifier AS processedidentifier, f.name AS origname, f.identifier AS origidentifier, s.checksum FROM sys_file_processedfile AS s LEFT JOIN sys_file AS f ON s.uid=f.uid WHERE LOCATE(s.checksum, s.name) = 0
The interesting part is if the name in processedname does not contain (parts of) origname. Then you experience a bug I found today with the help of Camelia.
I am not sure what causes the bug, but its pretty obvious that at some point the uids of the processed file and the original file get mixed up and the database ends corrupted. This is however no problem, as we can simply flush the processed file cache once this bug is fixed.
Updated by Andreas Wolf about 11 years ago
After reading the issue description again, I realized that this is in fact a duplicate of #44073. The patch for this solves the issue with a wrong checksum, which lead to the original problem.
The hint I found with the non-matching checksum in filename and checksum column is therefore invalid - the search goes on...
Updated by Andreas Wolf about 11 years ago
- Status changed from Accepted to Needs Feedback
I will close this issue soon if nobody can reproduce this with 6.0.1.
Updated by Christian Tauscher about 11 years ago
This issue seems to be fixed with an update on 6.0.1
Thank you for your work.
Christian.
Updated by Andreas Wolf about 11 years ago
- Status changed from Needs Feedback to Closed
Closing this as presumably the problem has been fixed with 6.0.1