Epic #64570
closed
Properly handle different file systems in FAL
Added by Alexander Schnitzler almost 10 years ago.
Updated over 6 years ago.
Category:
File Abstraction Layer (FAL)
Description
Some time ago I realized, that the file system type (case in/sensitive) is set during a TYPO3 installation, which can cause serious troubles if you setup the system on a case insensitive fs, such as the ones of Windows and Mac.
This is a unnecessary pitfall because most websites are served by unix servers, that are case sensitive. So instead of silently detecting and setting the fs option during the installation we should go for strong defaults and a new installation step.
During the installation we could check for a case insensitive file system and warn the user that the default is case sensitive, but with the option to change that during the development phase with a hint to the consequences if one forgets to change that after the deployment.
Additionaly the reports module should be enhanced to show if the current fs matches the fs option of FAL and warn the user.
We have to consider these topics:
Install
- Should the Installer detect the FS or should we set the default for the default storage to case sensitive with the option to change it afterwards
General
- Changing the filename / directory name from upper case to lower case (and vise versa) on no case sensitive Filesystems (#25180)
Files
- Sprint Focus set to On Location Sprint
IMHO there are more pitfalls, if you move an installation from one OS to another (for example configuration of image magic), maybe we should firstly write an wiki article about such moves?
This issue can also happen if you move from one partition to another on MacOS X, if the first is ci and the second cs.
Is this meant to be satire? I don't want wiki articles but strong, sensible defaults and hints during the installation and in the reports module. What's the problem about that?
This isn't meant as satire. Is it a strong default, that you install TYPO3 on another system and them move this per file?
I don't have something against adding a warning in Installer/System Environment, as we already discussed on chat, but changing the behavior in the installer? Adding more "hints" which nobody reads?
Moved Slack conversion to file, to have it better readable.
Will add more issues to this EPIC to have everything according to the fileSystem in one epic.
- Description updated (diff)
Alexander Schnitzler wrote:
Some time ago I realized, that the file system type (case in/sensitive) is set during a TYPO3 installation, which can cause serious troubles if you setup the system on a case insensitive fs, such as the ones of Windows and Mac.
This is a unnecessary pitfall because most websites are served by unix servers, that are case sensitive. So instead of silently detecting and setting the fs option during the installation we should go for strong defaults and a new installation step.
During the installation we could check for a case insensitive file system and warn the user that the default is case sensitive, but with the option to change that during the development phase with a hint to the consequences if one forgets to change that after the deployment.
Additionaly the reports module should be enhanced to show if the current fs matches the fs option of FAL and warn the user.
Alexander Opitz wrote:
This isn't meant as satire. Is it a strong default, that you install TYPO3 on another system and them move this per file?
It's common practice that websites aren't developed on a live server, so yes, I see that as a strong default.
I don't have something against adding a warning in Installer/System Environment, as we already discussed on chat, but changing the behavior in the installer? Adding more "hints" which nobody reads?
How do you predict that nobody reads it? Having another step with a simple checkbox (use case sensitive fs), enabled by default, with a warning if your fs doesn't match is not even a big deal. If you do not have a case sensitive fs you won't even notice the difference, but vice versa you will. So why would someone ignore this hint when it causes a lot of trouble on live servers if not configured correctly?
You want in the installer a hint about that cs/ci thing. But you also mention that the users move their installation by file to the live system. So they don't use the step installer again. So what is the benefit of another step?
The warning in Installer/System Environment, where I'm with you, is a benefit, also a hint that the GM/IM configuration do not match any more is a good hint after such a system switch.
I don't just want a hint in the installer but a checkbox to choose the fs from which defaults to case sensitive. If you plan to work/release your system on a case insensitive fs later on, you can decide to switch to a case insensitive system during the installation. It's simply a bad habit detecting the fs during the installation and assume it doesn't change. It's like russian roulette because the effects of a wrong settings on a live server are way more severe than a wrong image magick setup for instance.
It's simply a bad habit detecting the fs during the installation and assume it doesn't change.
You can change it, per defined storage, so what is wrong? What does it help if you have a a checkbox in the step installer, if you deploy per file on the live box, do you start the step installer?
But maybe we understand us both wrong and you don't mean inside the step installer.
- Description updated (diff)
- Sprint Focus changed from On Location Sprint to Remote Sprint
- Status changed from New to Needs Feedback
Alex, any concrete todos what we can improve here?
- Status changed from Needs Feedback to Closed
- Sprint Focus deleted (
Remote Sprint)
Spoke with Alex and we decided to close this issue.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by