TYPO3 Core

Well, an exception from FAL is ok to indicate a missing file. But the exception needs to be handled by the component using FAL.

Can you tell us the exact steps, so this can be reproduced?

It is related with https://forge.typo3.org/issues/55514

I used "Uses case sensitive identifiers" with "no" on a linux system. Every time when a user uploaded files with upper case letters i got this error message. Every time the file upload and the widgets werde blocked until i renamed the file to lower cases via FTP. OK, now i know i have to change "Uses case sensitive identifiers" to yes, but i am afraid the error is also thrown in other circunstances (e.g. renaming files via FTP?).

Are you sure? This doesn't sound like a upper case problem but a missing/renamed file problem.

If your adding, moving and deleting files through ftp you should setup the FAL indexing scheduler task so the db stays in sync with the file system. It also flags missing files that should prevent the exceptions in BE (for the core parts).

Well, i am sure :-)

In order to reproduce the problem try the following: New Installation TYPO3 6.2.4 on a machine with case sensitive file system (UNIX or LINUX). Then change in "File Storage" / Configuration the option "Uses case senistive indentifiers" to none. (Please note: Thats simply for reproducing the error - hopefully nobody does it in real life. But you can and it results in the described problem). Then go to file modul and upload an image with upper case letters in the file name.
Results:
- "(internal Server Error): Upload of file .... failed"
Well that is not correct, the image is uploaded. Via ftp you will find the file on the right place and with correct file permissions.
- the file name on disk contains the upper case letter(s)
- the file signature in data base contains only lower case letters
Then reload your filelist in the backend:
- result: "Oops, an error occurred! File /user_upload/test2/arme-Katze.jpg does not exist."
It does but FAL cannot find it because the file signature in data base is arme-katze.jpg - with lower case.
- in the file list you cannot use the folder which contains the wrong file anymore
- in the file and link wizards you cannot reach the folder anymore
Worst: when a user uses a wizard and click the folder, he is doomed, because every time when he opens again the wizard, the wizard shows the last folder with the exception. He cannot change the directory any more. An admin has to fix the filename on disk first.

Well that was for reproducing the error. Here is the real live scenario, which happens to me:

- first installation of TYPO3 on a system with case insensitive file system like windows or mac os. After filling the site with content the whole installation is deployed on UNIX or LINUX with case sensitive file system. Every link to an image with upper case letter in file name is broken, and there is no easy way to fix. The only way i found was changing all file names to lower case. (This exactly happens to me when i posted the problem.) When changing the option "Uses case sensitive indentifiers" to yes this solves the problem, but only for new images not for images which are already linked. file names in lower case cannot changed automatically to upper case file names.

- one step further: imagine an update of an existing TYPO3 4.5 installation: transferring the installation to a dev system without case sensitive file system, then do the update. The updater recognizes that the file system is case insensitive and so after update all file signatures in the database are lower case. When transferring back to server, the whole system is broken, not one single image with an upper case letter inside is shown any more and nearly all widgets are not usable any more. (please note: i did not try this scenario, but i am afraid it would happen this way).

Quote:

"If your adding, moving and deleting files through ftp you should setup the FAL indexing scheduler task so the db stays in sync with the file system. It also flags missing files that should prevent the exceptions in BE (for the core parts)."

Thats a nice and usefull feature, thank you for mentioning it - i didnt know it. But i am sure it cannot fix the this problem. And be aware that most members of our community are not full blown web developers but integrators or simply users without any deeper knowlegde. In my opinion there should not exist an exception which renders parts of the backand unusable simply by deleting an image via ftp. It would be enough to not show the image, dont it? And it should be possible to run a TYPO3 installation without installing a cron job. Dont misunderstand me: i dont want to argue against FAL - its a great feature! - i argue only against the existing exception handling which i consider a bug. Well, at least a quirk ... :-)

What is the solution if you have a hoster, where a cronjob is not possible? no cronjob = no sheduler = this error occurs again.
I have the same problem on a project where the hoster not allow cronjobs. Currently we try to switch the hoster.
I think it should be possible to use the BE also if a file is missing, maybe catch the exception, log it and show a error flash message, but a broken BE is bad.

The case sensitive part is very tricky. Maybe we should (again) make a list of all scenarios and check if we can improve current behavior. But switching between different file systems can give more problems than only the case sensitive part. UTF-8 support is also different on mac vs unix.

About the exception you are right. It should be catched and not break BE.

But switching between different file systems can give more problems than only the case sensitive part. UTF-8 support is also different on mac vs unix.

Yes, you are right - i missed this problem completely. Indeed, that could become a real serious problem when migrating an installation from one platform to another. A real nightmare in some cases.

About the exception you are right. It should be catched and not break BE.

That would help for the most smaller installation i think.

Discussion at the FAL Code Sprint 2015 in Essen and decision:

If you transfer a installation from a case sensitive filesystem to a case insensitive filesystem (or vise versa), you as the system administrator have to take care about different filesystems. TYPO3 can't handle that.

If you change the configuration of a storage containing files, TYPO3 must mess up, since the filesystem is present. The proposed solution must walk through all files and change the filename to the new storage configuration. This must be handled different for each filesystem and could take quite a lot of time, if you have to convert thousands of files.

So, we won't have a converter for changing the configuration of storages. Instead we propose issue #64617