Project

General

Profile

Actions

Bug #89461

closed

Errors with mixed case file names in case-insensitive storage

Added by Michael Stopp about 5 years ago. Updated 5 months ago.

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

0%

Estimated time:
TYPO3 Version:
9
PHP Version:
7.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

In a setup with a file storage, which is NOT defined as case-sensitive, there are several scenarios, in which mixed case file names aren't handled correctly.

My premise is: it's always a realistic scenario that mixed case file names can be found in a storage. e.g. if FTP uploads into a storage are possible. TYPO3 must be able to handle this correctly.

We can break the problem down into several test cases:

1. Mixed case file is uploaded in BE
Result: file name is converted to lower case, sys_file record is created correctly (ie. with lower case identifier + name). Everything works correctly.

2. Mixed case file is uploaded via FTP (Linux)
Result: accessing the target directory in the Filelist module will result in "Oops, an error occurred! File /MyTest.txt does not exist." No sys_file record is created. BE access to the directory is blocked (also to all other files/subdirectories!), as long as the uploaded file remains there unchanged.

This must be considered a bug. The best solutions would probably be to automatically rename the file to lower case and create the sys_file record accordingly. (This would basically be the same behaviour as with BE uploads.)

3. Mixed case file is uploaded via FTP (Windows)
Result: a sys_file record is created, but identifier + name are lower case, while the name of the physical file remains mixed case.

For the moment the file can be used in file references and it works in the FE. But the situation is far from optimal as the sys_file record doesn't reflect the reality of the file system (which will lead to errors, if the site is migrated from Windows to Linux). This can result in follow-up problems, eg. if the storage is later changed to case-sensitive. If the directory is accessed in the BE, a new sys_file record will be created (correctly with mixed case identifier + name). However the old record (with lower case identifier + name) remains, which must also be considered a bug, as there is no corresponding file in the file system. If the 'Update storage index' task is run, the file is not marked as missing, which must also be considered a bug.


Related issues 1 (1 open0 closed)

Related to TYPO3 Core - Bug #89517: Wrong sys_file record created by ResourceFactory->getFileObjectFromCombinedIdentifier()Needs Feedback2019-10-25

Actions
Actions #1

Updated by Susanne Moog over 4 years ago

  • Status changed from New to Needs Feedback

When uploading files via FTP (or any other non-TYPO3 means) it's the responsibility to use file names and paths compliant to the current configuration of the one doing the uploading. There are multiple cases where FTP upload / direct access to the folders may result in errors - uploading invalid files, insecure files, renaming / using invalid chars etc. To be save, the upload of TYPO3 should be used and is the preferred way.

If you absolutely need the option to handle ftp uploads, you may use FALs ability to use custom drivers. For example one way would be to use `\TYPO3\CMS\Core\Resource\Driver\AbstractHierarchicalFilesystemDriver::canonicalizeAndCheckFileIdentifier` in your custom driver to detect changes of the file identifier after the mb_strtolower and implement / use the same logic as when uploading a new file via TYPO3.

Actions #2

Updated by Jonas Eberle over 3 years ago

We might have just hit a problem with renaming files lowercase->uppercase. Investigating.

Actions #3

Updated by Christian Kuhn almost 3 years ago

  • Related to Bug #89517: Wrong sys_file record created by ResourceFactory->getFileObjectFromCombinedIdentifier() added
Actions #4

Updated by Riccardo De Contardi 5 months ago

  • Status changed from Needs Feedback to Closed

No feedback since a lot of time > closing it

If you think that this is the wrong decision or experience the issue again on recent TYPO3 versions (like 12 or 13) please open a new issue and add a reference to this one.

Thank you

Actions

Also available in: Atom PDF