current thoughts on install paths on Windows.

[aciddose]

yes the idea that this is a recent invention is laughable and shows just exactly how stupid most windows users are.

the home directory and application data directories have existed for decades. uh, well, nearly four of them now actually.

FOURTY YEARS.

then some amatures randomly implemented a bunch of crap, and 25 years later microsoft finally implemented the standards instead for the first time with their mass market products.

that was already twelve years ago.

So forty years ago, you couldn't easily move your applications and personal data onto a different disk ?
Twelve years ago, you were forced (by a standard) to use a hidden 'ProgramData' directory ?

no. twelve years ago you could move this directory to anywhere you want by applying two minutes of research effort using a tool like google search.

not sure about at&t unix but i'd be comfortable to assume it's likely that you could have changed it, even if it required a recompile.

[matt42]

Deleted

[aciddose]

i should have also mentioned it doesn't have to be hidden. that's a filesystem flag that you can change as you wish. there are other flags too, rarely used these days but still useful. for example the archive flag used to flag whether or not to track a file in backups.

show hidden directories, click on the directory, uncheck hidden, hide hidden directories, problem solved.

the feature in unix uses a period at the beginning of the name. so if you want to hide mydirectory, you just change the name to .mydirectory.

if you want it to show up you specify that in the browser or when you use ls or whatever. that eliminates the need for using a flag for such a common function. ms-dos and it's crappy implementation was limited to 8.3 filenames and this legacy like many others has continued all the way up to windows 8.

the purpose of hidden directories is not to make them secret. no, that's moronic.

the purpose is to solve the issue of when you have a lot of extra directories or files that you couldn't care less to see over and over again. for example you could go into your vst plugins folder and mark hidden all files that aren't dlls themselves. not a very practical application but one that would make sense assuming the list of vst dll files was useful in some way.

or in my case, applications install all this useless shit into mydocuments instead of using the proper application data directory. i don't want to see that stuff, it's useless to me and why the hell did they think it had anything to do with user documents? they're clearly bat-shit insane. so i can mark those folders as hidden and continue without being bothered by their idiocy.

[Andrew Souter]

Thanks for the input.

...so the consensus as of May 2012, seems to be there still is no consensus?


Seems maybe the best option is:


C://Program Files/ (obvious stuff)

C://Program Data/ (stuff that might have to be written by the app/plug, but the user needs not know about or interact with under normal circumstances)

Then we are left with user data, (user presets, sample data, large libraries etc.) I agree this folder should likely be customizeable by the installer and should be able to located on drives other than the primary system disk.

And I really can't understand why /Users/user/AppData/ should be hidden? Why hide user's data from them? It is THEIR data?? So I think we will avoid that location.

So user data will be fully customizable, and will default to:

C:\Users\user\My Documents\


Can anyone tell me why this plan sucks? Foresee any problems?

So it seems there is some potential issue even with this plan...

C://Program Data/ (stuff that might have to be written by the app/plug, but the user needs not know about or interact with under normal circumstances)

It seems not all users can write to this folder. Even an account with Admin rights, can not always write to this location if UAC is on? And yet the same account can do this successfully if "run as admin" is used... even though the user already has admin rights. WTF?

/program files/ of course is no-no also.

So where should preference files and similar things be kept so that users are NOT blocked to write to them as needed?

C:\Users\User\AppData\Roaming\Company\Product\potOfGold

??

What is the point of \programdata\ if it can not be written to?

This stuff is headache inducing, and by far the largest cause of support issues for us... At least 10:1, prob more like 100:1, as compared to any actual product support issues...

[arachnaut]

Windows File System Namespace Usage Guidelines:

http://www.microsoft.com/en-us/download ... x?id=22322

[mystran]

%appdata% yes, don't hardcode though, use CSIDL_APPDATA (with SHGetFolderPath or similar).

[Andrew Souter]

Windows File System Namespace Usage Guidelines:

http://www.microsoft.com/en-us/download ... x?id=22322

Thanks. This seems to be the most thorough info of the subject I have read thus far...

however, even this seems to give conflicting information.

Program Files vs. Per-User or Shared-Application Data
Windows Vista provides specific locations in the file system to store programs and software components, application data that is shared between all users on a computer, and application data that is specific to a user. These locations are, respectively:

C:\ProgramData:
o Storage location for application data that is to be shared between all users on that computer.

C:\Users\<username>\AppData:
o Storage location for per-user application data that is exclusive to a user and should not be shared with any other user on that computer.
o The AppData location itself has a further hierarchy below it to differentiate computer-dependent application data from computer-independent

and

Storing Shared Application Data
All application data that must be shared among users on the computer should be stored within the C:\ProgramData folder location. To store data for your application, create a subfolder under the C:\ProgramData\ folder by using the following convention:

...so if \programdata\ is meant to store data for ALL users, why can't a host app write to it when the current user using the host app even has admin rights??

[Andrew Souter]

%appdata% yes, don't hardcode though, use CSIDL_APPDATA (with SHGetFolderPath or similar).

Thanks. We will look into it.

[arachnaut]

...so if \programdata\ is meant to store data for ALL users, why can't a host app write to it when the current user using the host app even has admin rights??

There is a difference between having the rights and using them. When the application runs as a user that has administrative rights, it can inherit those rights and use them. But a user can't write into adminitrative folders without 'becoming' the administrator.

Actually, I know very little about these details, I came from a Unix programming background and I've pretty much forgotten everything.

The application should, I believe, create the AppData folders with the owner permissions of the user, not the administrator.

But, as I said, I'm not a Windows programmer.

[Jace-BeOS]

My current thoughts: the whole system sucks in terms of organization and complexity. File system layout, registry, program access, system feature access, etc. It's a pile of bad ideas, based on shallow-copying of other products, then changed in order to be arbitrarily different and unique to its own culture (that of verbosity and "correct but useless information" and to be able to say "we didn't copy anyone, we innovated"), then changed several times again to try to barely fit the ages-old standards that have survived the test of time (though also convoluted themselves; the unix culture isn't my ideal either but it functions when a good GUI is laid on top, like Mac OS X, though I felt classic Mac OS was ideal in layout and simplicity of management).

but you're not looking for my opinion.

[arachnaut]

You have to love the way Mac OS X makes gcc generate a.out as a package. That's real innovation.

[Christian Schüler]

I would abstain from using ~/Documents and stick with %APPDATA%, unless the user performs and explicit "export" or "save as..." operation.

Rationale:
Usually, the folder "My Documents" is just that, a folder for MY documents. That's the texts I write or the spreadsheets or presentations I create etc. Now imagine that every software and its uncle places a folder in ~/Documents. It clutters up soon! We had this situation on windows at one point in time, before there was a standardized location for save games. Many games intended to be nice and create a user visible folder for save-games under "My Documents". What feels like is a nice touch becomes a chore after the 10th game has done so. So stick to %APPDATA%, and provide a "reveal button" in the user interface to quickly take the user where his stuff is stored. This is the solution that I use.