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

Duplicate dxvk-cache/logs due to case-(in)sensitivity #2079

Closed
SirFrags opened this issue Jun 4, 2021 · 3 comments · Fixed by #2085
Closed

Duplicate dxvk-cache/logs due to case-(in)sensitivity #2079

SirFrags opened this issue Jun 4, 2021 · 3 comments · Fixed by #2085

Comments

@SirFrags
Copy link

SirFrags commented Jun 4, 2021

GetModuleFileNameW returns a string with the execution path case and not the actual path case. This causes the file extension detection for dxvk-cache/logs to be unsuccessful. Example:

Running GAME.EXE as GAME.EXE results in a file prefix of "GAME.EXE" while running it as "GAME.exe" results in a prefix of "GAME" causing two sets of dxvk-cache/logs.

Software information

Windows (10)

Possible solution

dxvk_state_cache.cpp

getCacheFileName()

if (extp != std::string::npos && exeName.substr(extp + 1)== "exe")
  exeName.erase(extp);

change to:

std::string extLower = exeName.substr(extp + 1);
for (auto& c : extLower)
  c = std::tolower(c);

if (extp != std::string::npos && extLower == "exe")
  exeName.erase(extp);

log.cpp

getFileName()

Same fix

misyltoad added a commit that referenced this issue Jun 4, 2021
Otherwise any game that has a .EXE instead of a .exe or some other casing variant will generate a bad state cache name.

Closes: #2079
misyltoad added a commit that referenced this issue Jun 4, 2021
Otherwise any game that has a .EXE instead of a .exe or some other casing variant will generate an incorrect log name.

Closes: #2079
misyltoad added a commit that referenced this issue Jun 4, 2021
Otherwise any game that has a .EXE instead of a .exe or some other casing variant will generate an incorrect log name.

Closes: #2079
@misyltoad
Copy link
Collaborator

Does #2080 fix it?

@SirFrags
Copy link
Author

SirFrags commented Jun 4, 2021

@Joshua-Ashton the pr fails to build but I made the intended changes locally and it fixes the problem - needs algorithm for std::transform instead of cctype

@misyltoad
Copy link
Collaborator

Well, cctype gives tolower :p

Ye, I just wrote that before i head out, will fix it up shortly.

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