If the app writes files into the installation, then you can't install in "Program Files", because Windows will capture and redirect those writes.
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.
Well written software follows guidelines from the NT age (%APPDATA%, %PROGRAMFILES%, etc). I have no idea why people still think its the dos age of just making arbitrary folders on the root. Heck, this is currently a huge problem in android. The root of my /sdcard is a mess. Are we forced to relive every mistake with every new platform?
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.
Yeah that's still a permissions issue. The user/account did not have write permissions so instead of just erroring out its trying to preserve legacy software by taking the change and ignoring it silently. Who knows why MS chose this path but the fault is still on the installer.
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.
Apps should write data files to %APPDATA%, not Program Files where the executables shall reside. The only excuse for installing to c:\chocolatey is lazyness
In this case, Chocolatey's data files are actually program files for the rest of the system.
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.
> The Von Neumann architecture won over the Harvard architecture for a reason
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.
This is just plain naive. See Shorel's comment, and to that I'll add:
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.
For Python what may be happening is a good piece of software that is not native to Windows. It works well enough on Windows, but the windows installer is very low on the developers' priorities and expertise. So the windows install experience ends up an afterthought that just barely works.
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.
Treating the space as just another character in a path means that sometimes paths have to be placed inside quotes so the space isn't taken for the end of a commandline arg. Some old software didn't do that.
The tilde file names in windows harken back to ye olde days of MSDOS, where file names were only allowed to be 8 characters long, and the extension was only allowed to be a dot followed by three characters (aka: the "eight-dot-three" file naming convention).
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.
