Bug #66209

ProcessedFile::setName checks existence for new objects

Added by Marc Bastian Heinrichs almost 6 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
-
Start date:
2015-04-01
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

A type safe comparison in ProcessedFile::setName leads to the problem, that the existence for new object is checked.

For a new ProcessedFile $this->name is NULL but is compared type safe to an empty string.

Stumbled over this with following scenario:
A solr indexer configuration indexes a field with a path to a scaled image (FILES with IMG_RESOURCE). This indexer runs in user context (_cli_scheduler), that's why permissions evaluated in the ResourceAPI.

Because $this->name is NULL, this check in function setName

// Remove the existing file
if ($this->name !== $name && $this->name !== '' && $this->exists()) {
    $this->delete();
}

leads to a existence check which leads to a Storage::hasFile check which leads to a assureFolderReadPermission() on folder NULL.

This fails for _cli_scheduler. In general this is okay, but we are in a FE like imageScaling context here.

And, of course, checking the existence for a new ProcessedFile object with name NULL is a bug.


Related issues

Related to TYPO3 Core - Bug #86399: Wrong processed folder resolved, when folder is configured to be on a different storageClosed2018-09-27

Actions
#1

Updated by Marc Bastian Heinrichs almost 6 years ago

Patch in gerrit will follow.

#2

Updated by Susanne Moog almost 2 years ago

  • Related to Bug #86399: Wrong processed folder resolved, when folder is configured to be on a different storage added
#3

Updated by Susanne Moog almost 2 years ago

  • Status changed from New to Closed

Fixed with #86399

Also available in: Atom PDF