IME "root of C: drive" default install location is often a sign that software has bugs when run from paths containing space characters.
Cygwin goes to c:\cygwin because it's normal for all sorts of files in that directory to be written/changed. If it were in "Program Files", it wouldn't work at all.
To call this a bug is just absurd. It's Microsoft that changed the notion of what was valid and forced everyone else to conform. Some software isn't able to conform.
It's just a simple consequence to the fact that Chocolatey is not 'a program' with clearly defined 'data files', but a general purpose software manager (and one that should really be a part of Windows).
The Von Neumann architecture won over the Harvard architecture for a reason. You should learn about it.
And then we placed restrictions on it for another reason: security.
See Data Execution Prevention http://en.wikipedia.org/wiki/Data_Execution_Prevention Which, like these file system permissions, attempts to divide storage into things that you can write and things that you can execute, and the two only meeting in special cases.
You're saying that Chocolatey needs elevated privileges to do it's special thing. Sure. Then it shouldn't be designed around the needs of users who can't get those permissions.
That is YOUR definition of where to write data files. Not mine and certainly not everyone's idea. Saying that all apps should fit this model is just absurd.
Well, Him and the designers of the operating system.
I have no idea what capturing and redirecting writes mean. If you want to write, write somewhere you have permission to write to. I deploy software and sometimes need to changeup permissions for badly written software that likes to write to its install folder. I don't know why people excuse developer laziness like this. Imagine if your linux configs were written to /bin/ instead of /etc/ or stuff that should be in your profile is written to /sbin/ or if your logs were put in /etc/. Thats the linux equivalant of what lazy developers do to Windows.
All explained here:
http://superuser.com/questions/384107/why-cant-i-edit-a-prog...
The fix is either use the proper locations for app data OR change permissions on that folder. its not some insurmountable hurdle that forces you to use weird locations. If permissions were correct then it would be fine. Heck, install Apache on windows. Everything just works in the proper locations because they didn't half ass everything.
Its also worth mentioning that this change came along when Vista was released; prior to that this didn't happen, yet crappy installers pulled the same shit: install to c:\, attempt to write to c:\windows\temp, etc and other DOS/Win95 legacy habits.
Ironically, Vista helped fix all this. Now I see installers for open source or community projects uses proper locations much more often than not. I guess people got sick of the UAC prompts and corporate admins were complaining about how all these arbitrary writes weren't compatible with their limited users.
It also shows how anyone claiming "my tool is special, unlike others it's better to install this under C:\" is not showing good neighbourliness. It just encourages others to make the same mistake.
For Oracle, that probably also holds ... except maybe for the "good software" part.
If your flag is for a path, you can assume everything up to the next flag is a path name.
myprog -filename here is my path with spaces -another_flag
Of course this depends on how the shell gives the arguments to the program.
On the other hand, there is no excuse why some GUI programs cannot handle spaces.
So, that's just one file?
Like, if someone generated several thousand files, all named: "New Text Document.txt"
In the background, some versions of Windows will also record an alternate file name for ye olde backwards compatibility, such as:
NEWTEX~1.TXT
NEWTE~10.TXT
NEWT~100.TXT
NEW~1000.TXT
NE~10000.TXT
N~100000.TXT
It's not really about the space characters, so much as it is about length constraints from back when 640KB should've been more memory than anyone will ever need.