Don't.
Well, this was a short one. :)
From the very start of its existence, ZFS supported case-insensitive datasets. In theory, if you share disk with Windows machine, this is what you should use. But reality is a bit more complicated. It's not that setting doesn't work. It's more a case of working too well.
Realistically you are going to be running ZFS on some *nix machine and access it from Windows, it'll be via Samba. As *nix API generally expects case-sensitivity, Samba will dynamically convert what it shares from the case-sensitive world into the case-insensitive one. If file system is case-insensitive, Samba will get confused and you will suddenly have issues renaming files that differ only in case.
For example, you won't be able to rename test.txt into Test.txt. Before doing rename Samba will if the new file already exists (step needed if underlying system is case-insensitive) in order to avoid overwriting unrelated file. This second check will fail on case-insensitive dataset as ZFS will report Test.txt exists. Because of this check (that would be necessary on case-sensitive file system) Samba will incorrectly think that destination already exists and not allow the rename. Yep, any rename differing only in case will fail.
Now, this could be fixable. If Samba would recognize the file system is case-insensitive, it could skip that check. But what if you have case-sensitive file system mounted within case-insensitive dataset? Or vice-versa? Should Samba check on every access or cache results? For something that doesn't happen on *nix often, this would be either flaky implementation or a big performance hit.
Therefore, Samba assumes that file system is case-sensitive. In 99% of cases, this is true. Unless you want to chase ghosts, just give it what it wants.
That’s great, but how do I deal with the situation where data *also* gets added from a truly case-sensitive environment, and I end up with (due to inconsistent naming, either by users copying over data or inconsistent programming):
/data/libraries
/Data/libraries/presets
/Data/Libraries/presets
/Data/Libraries/Presets
/merged/readme
/merged/Readme
/merged/ReadMe
/merged/README
Windows gets utterly confused, and will only show you the content of whichever one was opened first, making the rest of the data virtually inaccessible…
Short answer is that there’s no good solution when you have two players with completely different understanding of the world. Setting ZFS to support case-sensitivity wouldn’t actually solve this issue albeit it would warn you of conflict earlier on. Depending on what your use case is, that might be desired.
On my part, I just ignore this as I don’t have it happen often. Most of my samba stuff is used remotely and samba takes care not to have such overlap. For cases when I care about fidelity (e.g. backup from Linux system), I access them via SSH/SCP.
It’s not ideal but it’s the poison I picked. :)
BTW, for the renaming issue you describe, there is an easy workaround, whereas I cannot see one for the situation I describe…
Workaround:
test.txt > test2.txt > Test.txt
Yes, a bit of a kludge, but it works…
True, this works but it gets annoying quite fast. Thing is, I need to change case way more often than I need to deal with duplicate files so for me that kludge would drive me crazy. For someone who often deals with intentionally duplicated files (like the example of merged directories you gave above), math is different.
If math ends you on a side where you need to have case sensitivity – workaround you mention is not a bad solution.