notice - Contribute
Check case sensitivity setting in `File storage` record
Most problems rises when you are migrating from case-insensitive to case-sensitive file system, or when auto-generated File Storage didn't recognize case-sensitivity correctly.
In such situation created File storage saves file identifiers with lower-case in DB and can't find files which has mixed case.
- Find all File Storages via module List on 'page zero' and on tab Configuration check the Uses case sensitive identifiers checkbox.
- This error occurs when a media resource (image, PDF) is deleted from the server but remains linked via the "media" extension and FAL.
- The message appears when the file is in the directory but not the record in the DB.
- In my case happens when you upload a file with the name in uppercase. This is upload but the record is not created. Solution: delete the file from the directory and upload the file in lowercase (first check if setting case sensitivity in File Storage record doesn't help).
Situation: Upgrade from 6.1 to 6.2
This error occurs at this step of the upgrade process :
Migrate all RTE magic images from uploads/RTEmagicC_* to fileadmin/_migrated/RTE/
The solution is to update the general reference index (sys_refindex) via the Typo3 Backend :
TYPO3 backend, ADMIN TOOLS > DB check > Manage Reference Index
(Francois (talk) 14:20, 1 June 2015 (CEST)) This didn't work for me, because the problem was different: the migration wizard (rather stupidly) takes the first File Storage that it finds. File Storages are sorted by name. In my case, I happened to have some Storage which came before the default one. When the update wizard tried to check if the file had been moved properly, it couldn't find it in that Storage. My workaround was to rename my default Storage to "00 - Default", which made it the first to be retrieved.
Situation: Upgrade from 4.5 to 6.2
This error occurs at this step of the upgrade process:
Migrate file relations of tt_content uploads
It occurs for files containing latin characters (æ,ø,å,..). The solution is to change default sys_file_storage (fileadmin/ (auto-created)) directly in DB. Field 'configuration' in XML text for variable for 'caseSensitive' set to '1'. Restart/continue migration.
Situation: Upgrading from very old DAM versions
DAM versions up to 1.1.7 allowed users to circumvent TYPO3's file and folder name sanitization, so users could enter files containing e.g. space characters. While that may not have caused any issues on TYPO3 4.x, it will result in various obscure errors in 6.x, not just this exception.
DAM 1.1.8 added sanitization but still failed to sanitize folder names when renaming existing folders. This issue has been fixed later (at latest on 1.2.4, exact release not identified yet).
As 1.1.8 fixed most of these issues and was released just one day (25 January 2011) before TYPO3 4.5 you should only encounter this issue on very old TYPO3/DAM installations.
Solution: Identify all file paths containing spaces which are currently in use (to keep amount of work low) via database and rename them manually. Warn your editors to check file names if currently unused files are affected (simply remove the
number_of_references condition below). Assuming reference index is reliable:
SELECT * FROM sys_file WHERE identifier LIKE "% %" AND number_of_references > 0;
Situation: Entering Upgrade Wizard after upgrading to 8.7
Exception gets thrown when entering Upgrade Wizard:
Uncaught TYPO3 Exception #1314516809: File /user_upload/niederlandistik/bilder/foto_ba\'s.JPG does not exist. (More information) InvalidArgumentException thrown in file /var/www/t3dev.uni-oldenburg.de/htdocs5/typo3_src-8.7.17/typo3/sysext/core/Classes/Resource/Driver/LocalDriver.php in line 253. 21 TYPO3\CMS\Core\Resource\Driver\LocalDriver::getFileInfoByIdentifier("/user_upload/niederlandistik/bilder/foto_ba\'s.JPG", array)
This is caused by TYPO3\CMS\Form\Hooks\FormFileExtensionUpdate::checkForUpdate() getting called, which calls $persistenceManager->retrieveYamlFilesFromStorageFolders(). This seems to iterate over all files (which is not really necessary in any case)
See also: https://forge.typo3.org/issues/85685
The file does exist (though the file name is unfortunate):
ls -l fileadmin/user_upload/niederlandistik/bilder/foto_ba\\\'s.JPG -rw-r-----. 1 user group 194414 Nov 1 2012 fileadmin/user_upload/niederlandistik/bilder/foto_ba\'s.JPG
Concequence Upgrade wizard no longer usable unless FormFileExtensionUpdate is disabled or issue with this file is fixed. Setting configuration presets from "Debug" to "Live" does not help.
Important Set configuration presets to "Debug" to see where problem occurs (You should not do this in production system though).
For this specific case: (the exception may be caused by other things, though)
- "Fix" the filename.
- Mark FormFileExtensionUpdate as done
These are workarounds, not solutions!!!