Bug #55514

Create new file or upload with Uppercase filename results in lowercase filename

Added by Jan Kiesewetter over 7 years ago. Updated over 6 years ago.

Should have
File Abstraction Layer (FAL)
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


If I create a new file "Test.html" or folder "Test2" the file and folder will be created lowercase "test.html" and "test2".
Also every file I upload is renamed to lowercase.
I work with the current master branch.
This confuses me because of the uppercamelcase convention of Extbase.

Is this an intended behavior?

Related issues

Related to TYPO3 Core - Bug #55359: Image files with uppercase file extension don't work in element browser and content elementsClosed2014-01-27

Related to TYPO3 Core - Bug #55652: Upload a file with Uppercase letters --> Error in filelistClosed2014-02-04

Related to TYPO3 Core - Bug #70172: Don't change file or directory identifier on createRejected2015-09-29


Updated by Frans Saris over 7 years ago

  • Status changed from New to Needs Feedback

Is the "Uses case sensitive identifiers" checkbox checked for your File Storage?

If not all file names are changed into lower case.


Updated by Bernhard Kraft over 7 years ago

Where can I find this option?


Updated by Tobias Wollender over 7 years ago

Didn't know of this option either. But it is on the rootpage (id=0). There you find your storages (e. g. fileadmin) and you can set the option "Uses case sensitive identifiers" there. For me it works to upload/create case sensitive files/folders with current master.


Updated by Jan Kiesewetter over 7 years ago

OK, this option also works for me.
But, as this is a new option the default should be the old behavior.


Updated by Frans Saris over 7 years ago

Did you run the upgrade wizards? These check if the filesystem is case sensitive and the value for each existing storage.

Gr. Frans


Updated by Alexander Opitz over 7 years ago

No feedback within the last 90 days => closing this ticket.

If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.


Updated by Alexander Opitz over 7 years ago

  • Status changed from Needs Feedback to Closed

Updated by Lars Houmark over 7 years ago

I would like to see this reopened as I consider this a bug.

First of all the checkbox is off by default which can break systems that is case sensitive. It should be on as it seems that all system will work without problems (my local dev on Mac OS X will work just fine, but our production servers won't as they are case sensitive.

Second, if the checkbox is off, then TYPO3 should lowercase the uploaded file to ensure that it does not break - but this is not possible for files, since they may have been uploaded by other means, like deployment or FTP directly. Still, TYPO3 itself should lowercase the files when uploading, because the entire file selector breaks when a file with uppercase chars is uploaded and the checkbox is off.



Updated by Peter Linzenkirchner about 7 years ago

I support the statement of Lars Houmark. "Off" as default ist indeed a bad solution:
- most sytems are case sensitive
- default on would work on all systems
The default should be changed to "on".


Updated by Peter Linzenkirchner about 7 years ago

Frans Saris wrote:

Did you run the upgrade wizards? These check if the filesystem is case sensitive and the value for each existing storage.

Gr. Frans

i didnt read this before my last answer. I can reproduce the problem now: I am used to install and update on my local test machine with mac os X which is not case sensitive and put the whole installation to the live system. it is is a tricky trap, i think. Many developer work on windows or mac os x and put the whole stuff to live on linux or unix.

Imagine the content is put in a new installation on DEV machines on Windows or Mac (or an complete update to 6.2 is done on DEV) and all idetifiers are transformed to lower case. After transferring to life on unix or linux none of them is working any more and the whole file upload system with all widgets are broken.


Updated by Frans Saris about 7 years ago

The fal indexer should recognise existing files by content hash and update the correct existing index record.

So running the indexer task in these situations should fix your issue.


Updated by Andreas about 7 years ago

On a MAC you get wrong data for the identifier in the sys_file with the Update Wizard.
Update was done offline on a MAC - took me quite long to figure out, that with the regular UPDATE WIZARD you can't do the update on a MAC - you'll get always wrong data for the identifier in the sys_file. No difference if you check the case sensitivity in the storage.


Updated by Stephan Jorek about 7 years ago

There is a related issue https://forge.typo3.org/issues/57695 with its corresponding feature-branch https://github.com/artplan21/TYPO3.CMS/compare/TYPO3:master...feature-57695-fal-unicode-normalization (not yet up-to-date anymore)…

Any feedback is (very) welcome …


Updated by Jan Kiesewetter about 7 years ago

My point is, a file which is uploaded or created from a editor must not be renamed to lowercase regardless of the file system.
The file could be linked in the frontend and than has an unintended name.

If renaming of files while uploading or creating should be a feature, then the configuration should be changeable.


Updated by David Bruchmann almost 7 years ago

I think the default setting is a bug too, especially because the Update-wizard is using upper-case-paths like migration/RTE/RTEmagicC...

So with the lower-case default-value the whole migration process is not working and it's hard to find the reason because in many cases TYPO3 is just not printing the html for the image-tags if the images can't be found.

I don't know why the option was invented at all but the current default setting at least is breaking a lot and definitely wrong.


Updated by Urs Braem almost 7 years ago

I've upgraded a site from 4.5 to 6.2 on a Mac with MAMP. I did notice the issue with this setting and during the upgrade, I enabled "Uses case sensitive identifiers" for the default file storage record "fileadmin".

Now I deployed this to a regular CentOS hosting with suPHP.
In the file storage record, "Uses case sensitive identifiers" is still enabled:

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
        <sheet index="sDEF">
            <language index="lDEF">
                <field index="basePath">
                    <value index="vDEF">fileadmin/</value>
                <field index="pathType">
                    <value index="vDEF">relative</value>
                <field index="caseSensitive">
                    <value index="vDEF">1</value>

In the file system, most directories have mixed case.
Nevertheless, most file paths are output in lowercase.
Some file paths are stored as duplicates, upper- and lowercase.

Most file links on the site don't work at all.

I'm just one step before renaming everything to lowercase in the filesystem
and in sys_file. Although that sounds very much like a bad idea.

What should we do?

@Frans, what do you mean by "The fal indexer"? The reference index updater? I've been running this many times and "index integrity is perfect"


Updated by Urs Braem almost 7 years ago

Ah I found it. It's the scheduler task "File Abstraction Layer: Update storage index (scheduler)". Yay!


Updated by Urs Braem almost 7 years ago

BUT the scheduler task didn't correct all entries. I had to do it manually. I wasn't sure if it only took the sys_file entries where the filename had some uppercase characters. Is it really supposed to correct paths and file names, if the case is wrong? Or did I try the wrong tool?


Updated by Urs Braem almost 7 years ago

I see. Haven't tried it yet, but I guess the "Update storage index" scheduler must run on the non-case-sensitive system (with the "Uses case sensitive identifiers" option enabled in for the storage record), in my case, locally on the mac. On a case sensitive system (=the live server with apache) it won't find the corresponding file (example: sys_file saying myfile.pdf, filename being MyFile.pdf, Linux won't be able to find that file)

An approach to do it on thecase-sensitive system would be to do it (supposedly) the other way round: start with the file storage, not with the sys_file table: run through the file storage and compare found files with sys_file and do the corrections in sys_file accordingly.


Updated by Urs Braem over 6 years ago

In a new case, I ran the FAL scheduler task locally (i.e. on a case insensitive mac), and received nearly correct sys_file data. But funny enough, the entries in sys_file for files in fileadmin/_migrated/media resisted being rewritten to the correct uppercase spelling. So all the images from the media field weren't displaying on the linux server.

I solved it by rewriting the file names to lowercase (http://stackoverflow.com/a/7787159/160968), as just this directory was concerned. But that's of course not a hack that's viable for all cases.

Also available in: Atom PDF