TYPO3 Core

Where can I find this option?

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.

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

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

Gr. Frans

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.

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.

FWIW...

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".

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.

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.

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.

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 …

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.

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.

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" ?>
<T3FlexForms>
    <data>
        <sheet index="sDEF">
            <language index="lDEF">
                <field index="basePath">
                    <value index="vDEF">fileadmin/</value>
                </field>
                <field index="pathType">
                    <value index="vDEF">relative</value>
                </field>
                <field index="caseSensitive">
                    <value index="vDEF">1</value>
                </field>
            </language>
        </sheet>
    </data>
</T3FlexForms>

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
http://stackoverflow.com/questions/152514/how-to-rename-all-folders-and-files-to-lowercase-on-linux
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"

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

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?

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.

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.