On Windows, the wrong location is being used to save data.

[MicahZoltu]

The paths here are incorrect:
https://github.com/containers/container-libs/blob/main/storage/pkg/homedir/homedir_windows.go

The correct paths are:
Cache: https://pkg.go.dev/os#UserCacheDir or %LOCALAPPDATA%
Config: https://pkg.go.dev/os#UserConfigDir or %APPDATA%

The only time https://pkg.go.dev/os#UserHomeDir or %USERPROFILE% should be used on Windows is if the user is prompted with a save dialog box and you want to set the default location they are looking at. That directory is meant for user created files, not application configuration.

Anything in UserConfigDir should be assumed to be automatically backed up remotely, so it shouldn't contain large files.

When writing to Cache or Config directories, a folder for the application in question should be created as a subdirectory. You should not be writing loose files to any of these directories, nor should you be writing generically named folders to any of these directories.

The hardest part of fixing this is backward compatibility. Easiest solution is to check to see if the old location exists first, and if so use that and if not use the new correct location. Alternatively, you could migrate on startup, which would allow you to eventually delete the code for checking the old improper location.

[MicahZoltu]

Related: #140

[mtrmac]

Thanks for your report.

Yes, there are probably a lot of those kinds of problems in the codebase. Fixing that would be nice, in principle — a lot of the code is strongly dependent on Linux features, but some parts are not.

Cc: @l0rd

---

Anything in UserConfigDir should be assumed to be automatically backed up remotely, so it shouldn't contain large files.

AFAIK the Windows 8-10 “file history” does not backup %APPDATA%. I don’t think that’s a strong argument to violate platform conventions, just noting that for the record.

---

When writing to Cache or Config directories, a folder for the application in question should be created as a subdirectory.

This is somewhat problematic for this repo as a library which can be included in several different programs (and especially for the limited utility pkg/homedir). I suppose containers as a directory name would frequently work… but that probably needs to happen in the consumers of pkg/homedir, one at a time.

[MicahZoltu]

AFAIK the Windows 8-10 “file history” does not backup %APPDATA%. I don’t think that’s a strong argument to violate platform conventions, just noting that for the record.

The %APPDATA% folder is, by default, synced across the network on login/logout in school and corporate environments where users are frequently moving between physical computers (e.g., computer lab setup). This can also happen in more distributed setups, where user profiles are synced over the internet (likely over a VPN) and having a very large user profile is problematic.

---

This is somewhat problematic for this repo as a library which can be included in several different programs (and especially for the limited utility pkg/homedir). I suppose containers as a directory name would frequently work… but that probably needs to happen in the consumers of pkg/homedir, one at a time.

Is the issue that the application using this library doesn't provide any context about the application, so you don't know what name prefix to use? What happens if two applications on one device use this library, will they overwrite each other's content currently?

I'm not intimately familiar with this library so please excuse me if this is a naive/dumb question. I filed this here because an application that uses this library under the hood is writing data to the wrong location on my computer and spelunking lead me to this library as the source of the problem.

[l0rd]

At least this (inconsistent) situation is documented (Podman side). Ideally, we should fix that, but as mentioned by @MicahZoltu, dealing with existing installations may be tricky, especially as Podman is not the only consumer. And I am wondering how critical this is.

[MicahZoltu]

To use a crude analogy, I liken it to peeing in a pool. Technically, there isn't really anything bad that will happen if people pee in swimming pools. Urine is generally "sterile" and the chlorine will deal with any bacteria remaining. However, it is really frustrating to most pool goers when others pee in the pool, even when they know that technically it is probably no big deal.

In the case of this situation, this can be a nuisance of adoption in a shared computer setup because you have to manually exclude a bunch of directories for every app that does this, but those environments are becoming less and less common these days. People with automatic backups also have to deal with it, though a lot of backup software has code to ignore a bunch of "common" incorrectly located files. For everyone else, it is just annoying when applications put files on your filesystem in places they shouldn't go.

---

Perhaps as an intermediate solution, an environment variable could be read that takes precedence over the default? That way at least users who are frustrated with the incorrect defaults can override them easily?

[l0rd]

Picturesque analogy. But effective. In other words, that's about being good citizens. That makes sense.

@MicahZoltu, out of curiosity, which application consuming this library is causing you trouble?

[MicahZoltu]

TL;DR: podman-desktop -> podman -> container-libs

I now realize Podman is part of the same GitHub organization as this (I didn't realize that at the time I filed the issue). There is a semi-related issue in containers/podman#22875 which lead me to #140, which lead to the relevant code.

A related problem was fixed for Linux XDG paths a couple years ago in podman-desktop/podman-desktop#1770. I have a related issue open in podman-desktop/podman-desktop#16121, but I'm always a fan of fixing root cause upstream when possible which is why I also filed this issue here as well.