Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When in Windows, do as Windows does. #2458

Open
MicahZoltu opened this issue Apr 22, 2020 · 6 comments
Open

When in Windows, do as Windows does. #2458

MicahZoltu opened this issue Apr 22, 2020 · 6 comments

Comments

@MicahZoltu
Copy link

MicahZoltu commented Apr 22, 2020

Description

In Windows, the root of the user directory (%USERPROFILE%) is NOT the right place to store application settings. This is a very common convention on Linux, but Windows != Linux and not all Windows users want to pretend they are running Linux. On Windows, the correct location for application settings is %APPDATA% and the correct location for cache/large data is %LOCALAPPDATA% or %PROGRAMDATA% (depending on level of security consciousness).

%USERPROFILE% is the root of the user's space on the hard drive, and it is meant to hold documents that the user explicitly writes there (e.g., via a save dialog box) and to hold top-level folders for organization such as Documents, Videos, Pictures, and the appropriately hidden AppData folder (which is the default location where applications should be storing their data).

Along with the organization problems that is caused by storing files in %USERPROFILE%, it also presents problems with roaming profiles and backup scripts as Windows and Windows tools do not automatically sync/backup everything in %USERPROFILE%. For example, %APPDATA% will be synced over the network/internet on login/logout while %LOCALAPPDATA% will not. By storing files in the correct folders, the application is more likely to "just work" for users working in different environments.

I believe that Linux actually now has a standard for environment variables similar to the Windows one, so I would encourage fixing Linux at the same time (and cease writing to $HOME when those are present) but I don't personally care about Linux as much. 😄 MacOS X also has a convention I believe, though I'm not sure what Docker CLI does there.

Output of docker version:

Client: Docker Engine - Community
 Version:           19.03.5
 API version:       1.40
 Go version:        go1.12.12
 Git commit:        633a0ea
 Built:             Wed Nov 13 07:22:37 2019
 OS/Arch:           windows/amd64
 Experimental:      false
@MicahZoltu
Copy link
Author

MicahZoltu commented Apr 22, 2020

UPDATE: Oops, this is a test, not actual code. A quick glance doesn't show obviously where the problem lies.

homeKey = "USERPROFILE"

The naive solution to this problem is to just change this line to homeKey = "LOCALAPPDATA" (or APPDATA if everything currently stored is reasonable/safe to sync over the internet on logout) and I can submit a PR that changes that if desired. However, I recognize that there is probably a desire for some kind of migration process, which is a bit more complicated so I'll hold off on any such PR unless it sounds like the naive fix is acceptable.

@MicahZoltu
Copy link
Author

It appears the source of this problem is the utilization of the homedir package. If you are targeting Go 1.12+, the recommended fix is to just switch over to using either os.UserConfigDir or os.UserCacheDir as appropriate. This will fix things on Windows, Mac, and Linux I believe. I have filed an issue over with the homedir package you are using to try to get it fixed there as well, but the further from the application layer the harder it is to fix due to backward compatibility, so I would encourage addressing the problem at this layer (and dropping the dependency now that Go natively supports what you need).
moby/moby#40848

@silvin-lubecki
Copy link
Contributor

Hello @MicahZoltu , thank you for opening this issue 👍 This modification would be non-trivial as you said, so we need to check which path of migration would be the easiest.
Related to docker/for-win#5104

@ttutko
Copy link

ttutko commented Dec 11, 2020

Keep the following bug in mind when deciding to use the roaming or local folders: #2878

@MicahZoltu
Copy link
Author

Sadly, it appears that rather than fixing this the problem is getting worse. Docker (or possibly Docker Desktop) is now not only creating a .docker folder in %USERPROFILE% but it is also creating a .aws and .azure folder there as well.

What would need to happen to get fixing this prioritized? As a mitigation, at least making the directory that is used configurable via environment variable or something would go a long way to mitigating this problem for those of us who care, and won't require thinking at all about migration strategies.

Another simple solution that doesn't involve migration would be:

rootProfile = exists('%USERPROFILE%/.docker') ? '%USERPROFILE% : '%APPDATA%/Docker'

This way anyone who has an existing install with continue using %USERPROFILE% and anyone with a new install will use %APPDATA%/Docker.

@ariellourenco
Copy link

ariellourenco commented Jul 29, 2024

Hi team,

I am wondering if we have made any progress regarding this issue. I see a movement around the software industry to have the %USERPROFILE% folder clean again, with some prominent softwares already changing their configuration files to a more standard location.

Also, I am very curious about which process is responsible for the creation of .aws and .azure folders. Docker Desktop or Docker CLI?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants