Bug #68545

Logical mistake in checkFileActionPermission?

Added by Hannes Gesmann over 5 years ago. Updated almost 5 years ago.

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

0%

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

Description

Hey there,

I am a bit confused about a check in method RecourceStorage->checkFileActionPermission.
File: sysext/core/Classes/Resource/ResourceStorage.php

It says (TYPO3 Version 6.2.14), line 606ff.:

// Check 4: Check the capabilities of the storage (and the driver)
if ($isWriteCheck && ($isMissing || !$this->isWritable())) {
    return FALSE;
}

In human readable language:
IF (a write action is required AND (the file does not exists OR the storage is not writable)), THEN the required permissions are not granted.

So this check returns FALSE as soon as the file is missing – also in case that the storage IS writable…

From my point of view the code should be adopted like this:

// Check 4: Check the capabilities of the storage (and the driver)
if ($isWriteCheck && $isMissing && !$this->isWritable()) {
    return FALSE;
}

Am I wrong?
Feedback wanted. :)

P.S: Why is $isMissing checked anyway?

#1

Updated by Markus Klein over 5 years ago

  • Status changed from New to Needs Feedback

"is missing" is defined as "a file which was previously there (and has been indexed therefore), but which is gone now and therefore it is marked as missing in the index."
In the logic of FAL this check is fine, as you can't work on a non-existent file. (Note the distinction in FAL between writing to an existing file and creating a new one.)

So please get in touch with us on Slack and describe your usecase, so we can find out, what the right solution should be.

#2

Updated by Stefano Kowalke over 5 years ago

I have an example here where this issue takes full affect.

I have a folder with files which are also present in sys_file. At some point I need to delete them (the complete folder).

$storage->deleteFolder($folder, TRUE);
does this except it leaves the records in DB. Topic for another issue.

So I tried another approach

foreach ($oldItem->getImages() as $image) {
    $storage->deleteFile($image->getOriginalResource()->getOriginalFile());
}

That failed due to an error in fileperms

Uncaught Exception in TYPO3 CMS #1: Warning: fileperms(): stat failed for /path/to/user_upload/import/1440842296/1-31156_01.jpg in /Users/sok/Sites/TYPO3/6-2/typo3/sysext/core/Classes/Resource/Driver/LocalDriver.php line 1083

Also another issue. But that lead me to the thought that I could avoid check #5 by manually flag the file as missing.

foreach ($oldItem->getImages() as $image) {
    $image->getOriginalResource()->getOriginalFile()->setMissing(TRUE);
    $storage->deleteFile($image->getOriginalResource()->getOriginalFile());
}

But that never reached check #5 because of the described issue. I removed the $isMissing for check #4 and then I can delete the file.

#3

Updated by Stefano Kowalke over 5 years ago

@Marcus: One word to the

$isMissing
check in FAL. As far as I understood that (correct me if I am wrong) the
$isMissing
is set when the following happen:

1) There is an file in filesystem with a corrosponding entry in database.
2) I delete the file in filesystem
3) When calling \TYPO3\CMS\Core\Resource\Service\IndexerService::indexFilesInFolder() it should recognize that the file is gone and set

$isMissing
to TRUE.

What acutally happens that it fails with "File not found" Exception.

#4

Updated by Frans Saris over 5 years ago

Stefano,

Could you provide a code snippet so I can easily reproduce your issue? Or maybe even provide tests for this use-case :)

Gr. Frans

#5

Updated by Stefano Kowalke over 5 years ago

I will try to provide you with a working code snipped.

#6

Updated by Wouter Wolters about 5 years ago

Any update here?

#7

Updated by Alexander Opitz almost 5 years ago

  • Status changed from Needs Feedback to Closed

No feedback within the last 90 days => closing this issue.

If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.

Also available in: Atom PDF