Project

General

Profile

Actions

Bug #66209

closed

ProcessedFile::setName checks existence for new objects

Added by Marc Bastian Heinrichs almost 9 years ago. Updated about 5 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 1 (0 open1 closed)

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

Actions
Actions

Also available in: Atom PDF