Skip to content

Conversation

@towai
Copy link
Contributor

@towai towai commented Jul 31, 2025

The context for this is that i was symlinking files from a mod installation that were identical to the unmodded game, for space considerations, because i remembered having success with that in the past, before the project made the switch to ghc's filesystem library, it seems. (I was also much more pressed for space back then, but well, i thought writing a small program to check for matches and link them for me would be a good, not-so-difficult exercise...)

However i quickly started getting weird errors that it couldn't find GAME.CGO or KERNEL.CGO even when i hadn't touched them. Initially since i found that it occurred only when symlinking any files that were earlier alphabetically, i assumed it was some kind of index mismatch, but it was actually caused by a bug in an older version of filesystem.hpp causing the directory_iterator to read everything after a symlink as also a symlink, making them fail to be read properly: gulrak/filesystem#162

Adding f.is_symlink() is not as much of a change to the loop's condition from the previous behavior as it might first appear. It seems that even without that condition the iterator was reading symlinks before, just incorrectly (and before ghc::filesystem, they were being read just fine, iirc). With the new version, though, symlinks do have to be accounted for explicitly.

Given that the library's major and minor version are both the same, i don't expect there should be any breaking changes to the API, and i didn't find any when i was testing but there might need to be more investigation into that before merging. Also, without the added check for f.exists(), the behavior is exactly the same as if, for some reason, a fakeiso file the game needs just doesn't exist in the first place (which has no real reason to happen in a normal installation of the game): there's a decent chance it will either crash at some point later during runtime, or something will happen like a level failing to load causing Jak to trip infinitely. I thought it might be helpful to have it fail right away in the case that, say, someone moved their vanilla installation and staled their symlinks, but i'll defer to maintainers' judgement on that point.

@OpenGOALBot
Copy link
Collaborator

Can one of the admins verify this patch?

Copy link
Member

@xTVaser xTVaser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this is good, and makes sense, with symlinks in a directory essentially being lazy file pointers -- you won't find out if their targets exist until you try to access them.

@xTVaser
Copy link
Member

xTVaser commented Jul 31, 2025

ok to test

@xTVaser xTVaser merged commit 796e0a4 into open-goal:master Jul 31, 2025
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants