Project

General

Profile

Actions

Bug #62098

closed

typo3temp folder is flooded with fal-tempfiles-*.*

Added by Kay Strobach about 10 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
Start date:
2014-10-08
Due date:
% Done:

0%

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

Description

using 6.2 overtime the typo3temp folder is flooded with useless tempfiles by FAL, these files are not used anymore after doing some operations on them.

The FileObject having getForLocalProcessing should take care of deleting all the used files during it's __destruct.
Additionally a scheduler task to clear these files would be nice.
And the FAL temp files should be stored in a subfolder!

Is had an installation with about 1.5 million files in typo3temp, which match this pattern.

PHP Version 5.3-5.5


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #56982: files copied for local processing are not deletedClosed2014-03-17

Actions
Actions #1

Updated by Kay Strobach about 10 years ago

In the local driver there is

TYPO3\CMS\Core\Resource\Driver\LocalDriver::copyFileToTemporaryPath
which uses
AbstractDriver::getTemporaryPathForFile

and there you find

return \TYPO3\CMS\Core\Utility\GeneralUtility::tempnam('fal-tempfile-', '.' . PathUtility::pathinfo($fileIdentifier, PATHINFO_EXTENSION));

Actions #2

Updated by Kay Strobach about 10 years ago

/**
     * Create temporary filename (Create file with unique file name)
     * This function should be used for getting temporary file names - will make your applications safe for open_basedir = on
     * REMEMBER to delete the temporary files after use! This is done by \TYPO3\CMS\Core\Utility\GeneralUtility::unlink_tempfile()
     *
     * @param string $filePrefix Prefix for temporary file
     * @param string $fileSuffix Suffix for temporary file, for example a special file extension
     * @return string result from PHP function tempnam() with PATH_site . 'typo3temp/' set for temp path.
     * @see unlink_tempfile(), upload_to_tempfile()
     */
    static public function tempnam($filePrefix, $fileSuffix = '') {
Actions #3

Updated by Ingo Schmitt almost 10 years ago

  • Target version changed from next-patchlevel to 7.1 (Cleanup)
  • Sprint Focus set to On Location Sprint
Actions #4

Updated by Frans Saris almost 10 years ago

  • Status changed from New to Closed

Currently the only place in core (that we could find) where this happens is when you have a non-local storages and resize images. This will be fixed by #56982.

Actions #5

Updated by Martin Kutschker almost 10 years ago

There is another occurence. Here the copy is created without any reason I can understand:

ContentObjectRenderer->getFileDataKey($key) {
...
                case 'localPath':
                    return $fileObject->getForLocalProcessing();
                    break;
...
}

Try setting up a Filelist CE and try to see the "local" path:

tt_content.uploads.20.renderObj.20.data = file:current:localPath

What you get is a list of paths of newly created files.

The code in ContentObjectRenderer must be changed like this:

$fileObject->getForLocalProcessing(FALSE);

See FileInterface why FALSE is necessary here:

/**
 * Returns a path to a local version of this file to process it locally (e.g. with some system tool).
 * If the file is normally located on a remote storages, this creates a local copy.
 * If the file is already on the local system, this only makes a new copy if $writable is set to TRUE.
 *
 * @param bool $writable Set this to FALSE if you only want to do read operations on the file.
 * @return string
 */
public function getForLocalProcessing($writable = TRUE);
Actions #6

Updated by Anja Leichsenring almost 9 years ago

  • Sprint Focus deleted (On Location Sprint)
Actions

Also available in: Atom PDF