Primary config path different in Powershell and Bash

[jonashaag]

From using ccache 4.6 in a Windows GitHub Actions job:

In Powershell:

Primary config:   C:\Users\runneradmin\AppData\Roaming/ccache/ccache.conf

In Bash:

Primary config:   C:\Users\runneradmin/ccache/ccache.conf

[jrosdahl]

Thanks for the bug report.

This works as designed, so it would be helpful if you could describe what you expect. (This is why the bug report template has a section called "Expected behavior".)

[jonashaag]

I would expect them to be the same. It is very confusing that the paths depend on the shell you're using. (Unless a .bash_profile or similar is involved, but in this case I believe it's only due to the shell that's being used.)

But if it's expected behavior, feel free to close.

[jrosdahl]

I would expect them to be the same. It is very confusing that the paths depend on the shell you're using. (Unless a .bash_profile or similar is involved, but in this case I believe it's only due to the shell that's being used.)

It doesn't depend on the shell per se, only on the variables set in the environment that ccache is executed in. The bash environment (which I assume is bash from Git for Windows since you mentioned GitHub Actions) sets the HOME variable, and then ccache runs in what could be described as "Unix mode". In isolation, this makes sense to me since I guess the Windows bash environment is meant to feel like Unix. In Powershell and the classic Windows command prompt, HOME is not set so it uses %APPDATA%/ccache. Again, I guess that makes sense in isolation. (Or not: #946.)

But if it's expected behavior, feel free to close.

It's expected in the "it works as designed" sense, but the design could be improved. I personally don't use ccache in Windows and I don't have much knowledge on best practices when it comes to default locations for things in Windows. I agree that it sounds reasonable to unify the locations. However, I don't know to which one, and you didn't say which one you would prefer.

The background is simply that checking %APPDATA% after $HOME was done in 92cc99e by a contributor. The ccache Windows development is still largely up to contributors that are interested in Windows, now including you. 🙂

[cristianadam]

This can be achieved by using %HOMEPATH% or %USERPROFILE% on Windows instead of %APPDATA%. See https://docs.microsoft.com/en-us/windows/deployment/usmt/usmt-recognized-environment-variables

I tested on my Windows 11 box and got:

Git Bash:

$ echo $HOME
/c/Users/Cristian

Command Prompt:

$ echo %HOMEPATH%
\Users\Cristian

$ echo %USERPROFILE%
C:\Users\Cristian

%APPDATA% is the place where Windows applications should put their settings. This translates to the roaming profile, which might be what one would want in an organization, you could switch computers and get the profile settings, including the .ccache cache directory.

There is also the %LOCALAPPDATA% variable for the non-roaming settings.

I think people would be fine with %USERPROFILE% since ccache comes from Linux. 🙂

[jonashaag]

I have no informed opinion on config/cache locations on Windows. Just a naïve user who realizes the paths are shell dependent when using GitHub Actions.

The best suggestion I can make is to be inspired by how other cross-platform tools deal with this problem.

[jrosdahl]

Would %HOMEPATH% or %USERPROFILE% be preferable to %LOCALAPPDATA% as suggested in #946?

The best suggestion I can make is to be inspired by how other cross-platform tools deal with this problem.

Sounds good, but I don't have time to investigate this. Input from others would be welcome here.

[mrjoel]

TL;DR - I advocate for leaving things as they are, or rather will be after resolution of #946.

I think there are two separate but related questions raised, the first in #946 and the second here.

There is also the %LOCALAPPDATA% variable for the non-roaming settings.

I think people would be fine with %USERPROFILE% since ccache comes from Linux.

1. I am still of the opinion that for Windows-native executions the location and priority for config and cache I propose in Switch to using LOCALAPPDATA as default location on Windows #946 make the most sense for Windows locations. As a recap, my description uses %APPDATA% and %LOCALAPPDATA% exclusively. This best aligns with typical Windows semantics for usage, storing in the appropriate \AppData\ subdirectory depending on whether content is intended for sharing or local usage only.

   I'll again try to make a point of getting a PR put together for this, it's been creeping up and causing issues for me again recently.

2. The second question is my rephrasing of this issue and is a subtlety in the first question of "Windows-native" vs. non-native. Namely, "Should the process environment matter more or less than the process linked runtime?"

   This is not a question unique to ccache, in fact you'll commonly encounter similar behavior from many other executables. I view this as a net benefit and in the common cases where I want to more easily use an identical config I symlink my configs between Windows-native location and Unix-like-but-happens-to-be-on-Windows-kernel locations. There are notable times however, where one wants and needs to have separate behavior based on the execution environment.

   Edit: CCACHE_DIR already exists for the below described use case.
   There are situations where symlink is not available on Windows, these days mainly when developer mode is not enabled or enableable based on system policies.. For this and other reasons I've considered adding a separate ccache environment variable of CCACHE_HOME to allow overriding the home directory. This would offer a workaround to this issue where symlink isn't available (i.e., just put export CCACHE_HOME=${USERPROFILE} in a .bashrc or other shell config. It would also be useful for other reasons, including isolation of ccache data during multiple CI jobs execution by the same user. If that makes sense I'll add it and incorporate it into my PR for Switch to using LOCALAPPDATA as default location on Windows #946.

   The more general discussion needs to look at various Unix-like-in-Windows execution runtimes. The most common ones include MSYS, Cygwin, WSL1, and WSL2. Each of these offer different tradeoffs (and the ability to symlink multiple paths to the same file). Note in particular that Git for Windows uses an embedded mingw64 environment, most of which uses Unix-like semantics. The Git for Windows environment configuration tries to make the compatibility layer as thin and unnoticeable as possible, including setting HOME to match the Windows "home" directory, but there are places where the differences become apparent.

   What is being asked for here is to prioritize the executable type (i.e, plain WIN32 PE vs. PE linked to Cygwin vs. WSL ELF) to determine behavior over execution environment. I would suggest that this is an undesirable and non-standard change. The fact is that running git.exe from within Git Bash is explicitly a different execution environment than running the identical git.exe from PowerShell and ccache should likewise be flexible and continue to prioritize execution environment.

   Since the question is about the Git Bash environment specifically, it's instructive to consider what the Git for Windows git executable does. It first uses $HOME, then only if it is not set does it fall back to using ${HOMEDRIVE}${HOMEPATH} and finally ${USERPROFILE}. Notably this implies that git is less Windows native then ccache because git doesn't even consider or offer any APPDATA based locations. This arguably makes sense since in git the repo is the bulk of the data, not the config location, while for ccache the cache directory is the bulk of the size and there is therefore vested interest to distinguishing between local the remote data.

[jrosdahl]

Here are some other data points:

• sccache: "%LOCALAPPDATA%\Mozilla\sccache on Windows"
• Bazel: "[...] on Windows it defaults to %HOME% if set, else %USERPROFILE% if set, else the result of calling SHGetKnownFolderPath() with the FOLDERID_Profile flag set"

@mrjoel: If I understand correctly, the tools mentioned above use the same cache location in both execution environments. I'm leaning towards this for ccache as well since I think it makes sense. Not sure which location to prefer, though.

@jonashaag: I noticed that you said that ccache "works only in Bash" when linking to this issue. I would argue that ccache already works in both environments, so maybe there is some aspect to this that I'm missing. Does ccache-action depend on the location being the same in bash and PowerShell? If we go with @mrjoel's suggestion of keeping the locations separate, would you still consider that ccache only works in bash? If so, why?

[jonashaag]

I’m sure someone/we can get it to work.

[rkitover]

I'll try to work on implementing the design in #946 and followup there.