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.

Deleted

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.

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



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...

Windows File System Namespace Usage Guidelines:

http://www.microsoft.com/en-us/download/details.aspx?id=2232 2

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

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.



and



...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??

Thanks. We will look into it.

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.

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.

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