Bug #44616: Image caching broken for im_noScaleUp = 1 - TYPO3 Core - TYPO3 Forge

Custom queries

Accessibility
Easy tasks
Forge Triage
JavaScript issues
JavaScript Issues (w/o Epics/Stories)
My open issues
No feedback within 90 days
Open Bugs
Open issues of 10
Recently modified
Regressions
Stabilization Issues
Usability or UX

Watchers (2)

Christian Tauscher
Dave Witassek

Actions

Copy link

Bug #44616

closed

Image caching broken for im_noScaleUp = 1

Added by Christian Tauscher almost 12 years ago. Updated over 11 years ago.

Status:

Closed

Priority:

Must have

Assignee:

Andreas Wolf

Category:

File Abstraction Layer (FAL)

Target version:

6.0.1

Start date:

2013-01-17

Due date:

% Done:

Estimated time:

TYPO3 Version:

6.0

PHP Version:

Tags:

Complexity:

Is Regression:

Sprint Focus:

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.

Related issues 4 (0 open — 4 closed)

Related to TYPO3 Core - Bug #44073: Checksum needs to be updated after file processing

Closed

2012-12-17

Actions

Related to TYPO3 Core - Bug #45308: uid of processed file is sometimes updated during processing

Closed

Andreas Wolf

2013-02-09

Actions

Related to TYPO3 Core - Bug #58889: Checksum in generated images changes

Closed

2014-05-17

Actions

Has duplicate TYPO3 Core - Bug #45168: Wrong image displayed in FE if not resized

Closed

Andreas Wolf

2013-02-05

Actions

Issue # Delay: days Cancel

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by Christian Tauscher almost 12 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?

Actions

Copy link

Updated by Andreas Wolf almost 12 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).

Actions

Copy link

Updated by Andreas Wolf almost 12 years ago

Subject changed from Error thrown by FAL to Image caching broken for im_noScaleUp = 1

Actions

Copy link

Updated by Christian Tauscher almost 12 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.

Actions

Copy link

Updated by Camelia M almost 12 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.

Actions

Copy link

Updated by Andreas Wolf almost 12 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?

Actions

Copy link

Updated by Camelia M almost 12 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).

Actions

Copy link

Updated by Camelia M almost 12 years ago

It seems I have several files that have originalfilesha1 identical. I think this is not normal. Is it?

Actions

Copy link

Updated by Camelia M almost 12 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.

Actions

Copy link

#10

Updated by Andreas Wolf almost 12 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).

Actions

Copy link

#11

Updated by Andreas Wolf almost 12 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.

Actions

Copy link

#12

Updated by Andreas Wolf almost 12 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...

Actions

Copy link

#13

Updated by Andreas Wolf almost 12 years ago

Status changed from Accepted to Needs Feedback

I will close this issue soon if nobody can reproduce this with 6.0.1.

Actions

Copy link

#14

Updated by Christian Tauscher almost 12 years ago

This issue seems to be fixed with an update on 6.0.1

Thank you for your work.

Christian.

Actions

Copy link

#15

Updated by Andreas Wolf over 11 years ago

Status changed from Needs Feedback to Closed

Closing this as presumably the problem has been fixed with 6.0.1

Actions

Copy link

Also available in: Atom PDF

Project

General

Profile

TYPO3 Core

Custom queries

Watchers (2)

Bug #44616

Image caching broken for im_noScaleUp = 1

Updated by Christian Tauscher almost 12 years ago

Updated by Andreas Wolf almost 12 years ago

Updated by Andreas Wolf almost 12 years ago

Updated by Christian Tauscher almost 12 years ago

Updated by Camelia M almost 12 years ago

Updated by Andreas Wolf almost 12 years ago

Updated by Camelia M almost 12 years ago

Updated by Camelia M almost 12 years ago

Updated by Camelia M almost 12 years ago

Updated by Andreas Wolf almost 12 years ago

Updated by Andreas Wolf almost 12 years ago

Updated by Andreas Wolf almost 12 years ago

Updated by Andreas Wolf almost 12 years ago

Updated by Christian Tauscher almost 12 years ago

Updated by Andreas Wolf over 11 years ago