Bug #66209
closedProcessedFile::setName checks existence for new objects
0%
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.
Updated by Marc Bastian Heinrichs almost 9 years ago
Patch in gerrit will follow.
Updated by Susanne Moog about 5 years ago
- Related to Bug #86399: Wrong processed folder resolved, when folder is configured to be on a different storage added