Bug #84069
closed
ProcessedFile should load defined storage
Added by Frans Saris over 6 years ago.
Updated about 1 year ago.
Category:
File Abstraction Layer (FAL)
Description
The storage is defined in the sys_file_processedfile record and that value should be used. Now the storage assigned to the original file default processing folder is used.
But if you adjust the processing folder in a live installation or have some custom processing code that's able to use different storages to save your processed file this breaks.
- Status changed from New to Under Review
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Closed
Example: You're working with EXT:dropbox and you have opened the first folders, and list the first files. In that case sys_file_processedfile will be filled with records where column "storage" is the same as of the original file itself. In that case UID 2. Working with this remote storage is slow, so you set processedfolder to 1:/_processed_/dropbox (LocalDriver). But working on that storage is still very slow. It costs me hours to find out, that all records of sys_file_processedfile with storage 2 (dropbox) have to be deleted and created from scratch. While re-creating these records the sys_file_processedfile records get storage 1 now. And yes, now, working on remote storage is a lot faster.
The storage was already correct set:
https://github.com/TYPO3/typo3/blob/v12.4.5/typo3/sysext/core/Classes/Resource/ProcessedFile.php#L127
But this patch overwrites the previously correct storage again with the storage from the sys_file_processedfile record.
I would prefer to overwrite the storage only, if $this->storage is null.
Stefan
Also available in: Atom
PDF