Parity-ethereum: Use OS standard paths of application configuration files

[debris]

Currently parity directory is located under ~/.parity on all operating systems.

Should be:

• Mac OS: ~/Library/Parity;
• Windows: \Users\Username\AppData\Roaming\Parity (* not sure if Roaming is correct here).

Steps:

• [ ] Provide utility functions to determine correct path in an OS-independent way.
• [ ] Switch directories and provide upgrade mechanism.

[arkpar]

Why is it better?

[gavofyork]

For Mac OS it's perhaps arguable at present. However as it becomes less of a Unix CLI tool and more a cross-platform background service, it becomes better practice to use actual Mac OS paths. In any case, it's an awful lot easier to find files (I'm thinking of keys and dapps here) in the Mac OS Finder when they're stored in ~/Library rather than dot-files which are ugly and a PITA to show.

The case is more easily made on Windows, where $HOME/.parity is plainly wrong.

[NikVolf]

cargo uses $HOME/.cargo with no issues on windows

[gavofyork]

Just because you _can_ do it, doesn't mean you _should_ do it. We have had issues with users being unable to find configuration files/keys precisely because they were not stored in the expected, OS-standardised, place.

[rphmeier]

cargo and rustup are currently getting a fair bit of flack for not using XDG Base dir specification as well.

[NikVolf]

@gavofyork yeah i agree but also one thing is that on windows $HOME/.<folder> is much more accessible for regular user than hidden-by-default AppData/Roaming folder

probably keys should not be stored in hidden folder

[gavofyork]

reports in the gitter channel have so far not supported that assertion. /Users/User/.parity is an unexpected and non-standard place, regardless of whether Explorer happens to show it by default.

If there's an argument for allowing users to access key files directly (and I'm not sure there is) then it should be done in a proper way such as placing them in /Users/User/AppData/Parity/Keys or whatever, not some half-assed, lazy, non-standard, platform-blind hangover from Linux.

[MicahZoltu]

AppData/Roaming is _NOT_ the correct place for the blockchain as it is synced over the network on login/logout for Windows domain networks. It _is_ the correct place for things that you would expect to roam with the user such as private keys, user configuration, etc.

At the moment, Parity installs will likely break horribly on a domain network because of the installation of the blockchain (currently ~6GB for me) into the user's home directory which is then synced over the network (assuming default network configuration). Not likely a big deal at the moment since not a lot of corporate users install it, but will become a bigger issue over time as Ethereum grows in popularity.

See #2159 for more details on layout, or feel free to @mention me if you want clarification on the proper (MS endorsed) location for various file types.

[tomusdrw]

Might be useful: https://github.com/AndyBarron/app-dirs-rs

[tomusdrw]

Closed with #3828

[MicahZoltu]

@tomusdrw Unfortunately the attached change don't appear to resolve this issue. In particular, the chain data should go in AppDataType::UserCache of the used library, not AppDataType::UserData. By putting it in UserData, it is going to be put in a folder that may be a network share or a limited space disk (e.g. high performance low space SSD).

One could argue that the used library doesn't quite do the right thing for Windows as UserData should be in local, not roaming. I'll submit an issue over there about this as well.

[MicahZoltu]

Also, config (keys) should go in UserConfig, but it appears this change throws everything into UserData.

[MicahZoltu]

Issue to fix UserData in library: https://github.com/AndyBarron/app-dirs-rs/issues/16

[MicahZoltu]

I have submitted a PR at https://github.com/AndyBarron/app-dirs-rs/pull/18, if/when it is accepted a library update will resolve this issue. However, because migration is difficult I strongly recommend resolving the issue before you release the current set of changes (if it isn't too late already).

I'm not sure if anyone is seeing these comments as this is a closed PR, if someone is reading these, please let me know. If I don't hear anything on this issue I'll open a new one to help get some visibility as I believe the current solution is bad as it breaks Windows functionality (roaming replication/backup/storage).

[rphmeier]

@MicahZoltu hearing you loud and clear :) Thanks for taking a closer look into the best locations to keep things. The set of changes hasn't been in a published release yet, so no issue in changing it to something more relevant now.