Bug #89517
open
Wrong sys_file record created by ResourceFactory->getFileObjectFromCombinedIdentifier()
0%
Description
This was done on a Windows server with a case-sensitive file storage:
Name of file on file system: 'test.txt'
$resourceFactory = \TYPO3\CMS\Core\Resource\ResourceFactory::getInstance();
$file = $resourceFactory->getFileObjectFromCombinedIdentifier('1:/test.TXT');
Surprisingly, a file object is returned after executing above code, even though the file storage is defined as case-sensitive and no file with the name 'test.TXT' exists.
It turns out that a new sys_file record with identifier '/test.TXT' was created, which is clearly wrong, as no such file exists.
The Windows file system might not be case-sensitive, but file names CAN BE mixed case. If such a site is migrated to Linux, this will inevitably lead to problems, when identifiers in sys_file don't match the actual file name.
Updated by Susanne Moog over 4 years ago
- Status changed from New to Needs Feedback
A storage on a non-case-sensitive file system should not be configured to be case-sensitive, as that will not work out conceptually. Can you check if you have any problems, when disabling case-sensitivity for that storage?
Updated by Michael Stopp over 4 years ago
I hear your point about not using a case-sensitive storage on a non-case-sensitive file system. But I don't quite see, why it shouldn't work conceptually.
The other way round (a non-case-sensitive storage on a case-sensitive file system) definitely doesn't work conceptually, because you could no longer distinguish between test.txt and test.TXT, even though they are different files on the file system.
Why can't you treat a non-case-sensitive file system like it was case-sensitive? In the above example, FAL could say that there is no file named test.TXT on the file system, which is actually true. The fact that you could technically still access the file test.txt with the name test.TXT on the file system level, should not be relevant for FAL's answer. And FAL should certainly not create a sys_file record with an identifier that doesn't exist on the file system.
What I didn't mention in my original description: there was already a correct sys_file record for the file test.txt. So after FAL created a new sys_file record for test.TXT, you end up with two different sys_file records for the same file on the file system. I would call THAT conceptually wrong...
As I mentioned in my description: files DO have mixed case on a Windows file system. It's just not relevant for accessing them. But you can still deal correctly with mixed case file names, even if you're on a non-case-sensitive file system (e.g. don't create new sys_file records with identifiers that have no corresponding file...).
If you work in mixed environments and might want to move a site from a Windows to a Linux server, it would make life much easier, if you could just set all your storages as case-sensitive from the beginning. But then you have to rely on it being handled correctly.
Updated by Christian Kuhn almost 3 years ago
- Related to Bug #89461: Errors with mixed case file names in case-insensitive storage added