Comment 12 for bug 315782

It is correct that the kernel is that gating issue for making this change. There are technical issues that make the change difficult. The rename syscall is defined to be atomic to fix race and consistency problems with the original link+unlink behavior. Making an attempt to fix it in userspace, such as glibc or the application(s) breaks this requirement because the implementation would be equivalent to the original link+unlink. In addition, vfat requires an 8.3 alias name to also be created for compatiblility with the even older FAT filesystem. This makes it even more ugly. The 8.3 alias can be hidden in the vfat layer but it can have only one long name associated with it. The layers above don't know anything about this alias or the case insensitivity because, for the multiple other filesystems, it doesn't have to. All of these issues are solvable problems but a correct solution would have to invade all of the other filesystems and the upper (vfs) layer with case sensitive/insensitive state to work. This gets very ugly very fast.

The long and short of it is that the way UNIX/Linux handles case-insensitive filesystems is a compromise and every compromise involves giving up something. Making an atomic rename work correctly and cleanly in a pre-emptible, multi-cpu kernel where case sensitivity is the deeply embedded rule requires some things to go over the side, the issue in this bug being one of them. All in all, the compromises UNIX/Linux has had to make to accomodate these filesystems (VMS, MS, etc) have been better than the ones these other systems have tried to make to accomodate UNIX/Linux.

The chance of getting this change in the kernel is extremely slim on a number of grounds. The filesystem maintainers argued this down on technical merit 10+ years ago and have no interest in reopening the issue again. Without their support, and by extension, Linus's support, such a change would go nowhere. Some things we just have to live with.