Store shared data/config in ProgramData

[agersant]

On Windows, the correct location to store data and config files which are shared across all users is %ProgramData% (typically C:\ProgramData).
This PR makes the SharedConfig and SharedData reside there rather than in %appdata% which is a per-user directory.

I am not sure how this should impact the app_dirs version number. The API is the same, but it breaks the write -> read flow of SharedConfig and SharedData between the old and the new version. I think the right thing to do would be to call this a breaking change and bump the version number accordingly.

(Also, thanks for this very useful crate!)

[andybarron]

I intentionally didn't do this because C:\ProgramData is a hidden system directory on Vista, which means this will fail every time on Windows Vista. Supporting Vista might be pointless, but it seems disingenuous for a "cross-platform" crate not to support it. 😞

That being said, I also just realized that SHGetKnownFolderPath doesn't support anything before Vista. So we can either enable ProgramData and cut off support for XP and Vista, or we can revert to the CSIDL APIs (instead of known KNOWNFOLDERID), continue not supporting ProgramData, and officially drop both XP and Vista.

Alternatively, we could use Cargo OS detection and/or feature flags (or even runtime OS detection?) to do all this conditionally (e.g. disable ProgramData on Vista). Hm.

[agersant]

Hah, interesting. I suspected this might not be as trivial as I it seemed.

Where did you get the information about C:\ProgramData being a system directory on Windows Vista? I can't find anything on this subject, and also how does that make the directory unusable?

There is a CSIDL constant called CSIDL_COMMON_APPDATA pointing to C:\ProgramData (or C:\Document And Settings\All Users\Application Data on Windows XP). Could this be used to support all platforms at once?

[andybarron]

The source code for ActiveState/appdirs indicates that ProgramData is a
system directory on Vista, but I haven't verified it personally.

The CSIDL stuff does the same thing as the KNOWNFOLDERID stuff, but the
former is technically deprecated and is an alias for the latter on Vista
and later. Doesn't solve the ProgramData issue, but enables XP support.

Rust support on XP is already somewhat spotty IIRC, but it still feels like
something we should support (at about 8% total market share, compared to
Vista's 1%).

[agersant]

I did some more looking up about Vista. It seems that ProgramData at some point in time had very restrictive permissions by default. This might be the source of the comment in the Python source.

I'll install Vista in a Virtual Machine and see how things behave.

[agersant]

Alright, I got a Windows Vista VM up and running. The permissions on C:\ProgramData are set so that:

• Programs running as administrator have read/write access
• Programs running for regular users only have read access

Installing git for Windows (so I could clone app-dirs-rs) actually wrote in that folder and git works just fine.

Interestingly, app-dirs-rs fails to build not because of SHGetKnownFolderPath but because it can't find SetThreadErrorMode in KERNEL32.dll during linking.

[andybarron]

That would be due to Rust issue #35471. Apparently, LLVM only supports Windows 7 and above. Thus, you can't build Rust on Win <7, but your compiled binaries might run on older versions.

I'm now thinking we should stick with KNOWNFOLDERID and ditch older versions of Windows, but I'll have to think about it more - we have to find the right balance of ergonomics, ease of maintenance, and compatibility...

[MicahZoltu]

Applications are supposed to create a folder for themselves with necessary permissions on install, while they have elevated permissions, which is why admins have read/write and applications default to read-only to the root folder. I believe even on Vista, ProgramData as used by this PR is the correct solution.

As for Windows XP, it was end-of-lifed back in April 2014 and while it may have 8% market share, I strongly suspect that a very small portion of those 8% will be installing modern apps written in Rust. A good chunk of the machines running XP are doing so because they are in an environment where change is incredibly hard (e.g., government, enterprise, healthcare) and the chances that they are going to be installing some fancy new Rust application are near zero. Historically, Microsoft's end-of-life policies are pretty lax so you can be relatively sure that by the time Microsoft end-of-lifes something it is probably really at the end of its useful life.

[andybarron]

Consider me convinced. Merging!