CS5 install on case-sensitive file system - can't choose different drive (Mac OS)

Question

I just upgraded my macbook pro to a new drive and 10.6, and chose 'case sensitive' HFSX, 'cause I'm a heavy command line user and wanted the maximum BASH experience.
I'm trying to install the CS5 demo to try some web design tools, and the installer immediately says "Installation to case-sensitive drives is not supported. Please choose a different drive location to install." So case-sensitive drives aren't supported; crappy but fair enough.
The error message leads me to think that I can just choose a non-case-sensitive drive to install to, but I never get a chance to pick one - I click on the installer and it goes straight to the error message.
So - how do I pick a different drive to install to? Am I just an idoit, is there no way to select a different drive, or will it not install on a system that even BOOTS from a c.s. drive, regardless of the format of the drive that CS5 is installed to?
I called the support number, and the poor fellow on the other end suggested I re-download the demo, and if the new download fails call Apple support to report my 'drive error'.
I'm hoping to avoid an entire backup-reformat-restore and lose CLI compatibility just to try some demo software.
ch

Answer 1

That is part of why I would prefer case sensitive by default.   I know some server packages do the folding for you, same as some web servers do not differentiate between 'htm' and 'html' when people type in requests, but most of the time the backend server is going to be case sensitive and it is not safe to assume (or hope) that the service will fix things.  Compensating for mistakes is fine, but allowing such silent corruption is not a terribly laudable things and it encourage people be careless.
Every once in a while I do encounter someone submitting some work where their configuration values and file names do not match, and 'well my laptop silently fixes it for me since it does not care' is a poor excuse.  And if I sent broken filenames upstream or even worse commit them to be used on a server, that is a pretty significant professional failure.
Back to Adobe specifically, I have been trying the suggestion on poster mentioned in where one installs the Adobe applications to a case insensitive drive then copy over the installed files.  This does not quite work out of the box, but for reasons I would be hard pressed to believe are Apple's fault.
For instance the first error I encounter is the inability of Bridge to load:
"@executable_path/../Frameworks/WRServices.framework/Versions/A/WRServices"
When I go look inside the app directories I can see that in Bridge the file has been named 'awrservices', but in Illustrator it is correctly named AWRServices.   So it looks more like a problem in whatever version control they are using.  The only way I can picture (which my adminitialy limited knowledge of what I am sure is a large and complex project with all sorts of legacy issues) that the installer toolchain factors in as a problem is if they have mismatches in their own scripts/packaging and have been depending on HFS's bad behavior to hide the problem.  I can understand not wanting to invest the time to pay down the technical debt on such an issue, but having such errors in your configuration causes long term headaches.
And I say this as someone who worked on just such a project, moving a software suite that had legacy code stretching back longer than Adobe has existed as a company.  This conversion included moving from a case insenstive filesystem to a case sensitive one and yeah, there were lots of problems that the old FAT32 system hid from us, but it really paid off over the long run to fix them rather than try to twist the code to compensate.
Having said that, if the problem is really that they do not want to go update their filenames (in version control or config files), then you can always add folding to your loaders.  I have had to do that a few times due to upstream people developing on case insensitive systems and sending data files with incorrect file names.  This is an old class of problem, and while I can empathize with the struggles project managers have trying to get approval for paying down technical debt, the problem never gets better on its own and usually gets worse.
Which is why I responded with so much grump to the 'I never needed it' argument since that is exactly the type of customer comment that marketing tends to point to in order to push such things off the schedule.  This is the type of thing where the customer does not really know what they want because they are already accustomed to broken behavior and most of the problems are hidden from their immediate view.  It is easy to cover up the limitations since modern UI (and their search capabilities) can handle this. 
It is not just arcane developers stuff, and it is the same transition that people have made with things like spaces, quotes, and parentheses, where years ago users believed they had no need for them since they were not using them, but they were only not using them because they did not work.   Today try to tell a modern user they can not put (, ", ) or even ' ' in their filenames and they would rightly question why this piece of obvious functionality is not working since today they are used to it working and no longer automatically compensate for it.
I also find it ironic that by default OSX hides a number of file extensions, so from the user's perspective you can have multiple files with the exact same name displayed to them, so you can get display issues where 'foo' is the same as 'foO' if both have .txt, but 'foo' and 'foO' are not the same if one has .txt while the other is .pdf.  Add to this confusion cases like 'foo.txt' and 'foo.pdf" both being shortened to 'foo'.