-
-
Notifications
You must be signed in to change notification settings - Fork 22k
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
Warn on case mismatch on Unix systems #24860
Warn on case mismatch on Unix systems #24860
Conversation
575a7c9
to
bc964d5
Compare
There was already on open PR (#23441) fo this issue, but since I haven't reused any code from it, I have opened a new one to avoid messing with git history. |
Also notice that this is my first contribution and that I'm not a C++ expert. For example, |
bc964d5
to
22744d0
Compare
If I remember correctly, I couldn't use realpath for #23503 because while it has the correct behaviour on macOS, it is not guaranteed on Linux that the resolved path will have the correct case for the file, I will test it again later to confirm. Anyway thanks for taking a look at this ! |
Yes, you are right. I have tried it on my Ubuntu... I'm running out of clean solution... Perhaps this can be a first solution for at least macOS ? Since linux is unlikely to be case insensitive. |
Why doesn't the resolved path have the correct case on Linux? I don't see much in |
Oops, I tried it on my Linux system and indeed it seems to report unwanted things:
Those are due to |
Yes, i'm agree that this is not a good solution. |
That was the same conclusion I ended up with ^^ From what I saw while searching for this problem, there isn't an universal way on Unix systems to do that without walking the folder. Still since realpath seems to work as intended on macOS, were the problem is way more likely to happen (because case insensitivity is the default, while at the moment it's not even possible on ext4), it could be kept as a macOS only warning. |
Following symlinks is probably not a good behaviour ? |
@akien-mga Could system paths such as |
@EmrysMyrddin Oh yes you're right, I didn't think about symlink resolution, it certainly bring some problems. @Calinou But there would still be false positives if the user has symlinks in their project. |
Moving to next milestone for now as this doesn't seem ready to merge yet. Still no idea on how to solve this properly. |
@EmrysMyrddin Is this still desired? If so, it needs to be rebased on the latest master branch. Even though there are no conflicts, rebasing is important to allow testing how this behaves on master. Also, the above feedback should be addressed. Otherwise, abandoned pull requests will be closed in the future as announced here. |
@aaronfranke Yes it's still desired but I'm kind of stuck. I can't figure out how to solve the feedbacks. It seems that there is not clean way to do what we want, since "real path of a file" is not a real unix concept. I will rebase, but I don't now if there is a solution. |
22744d0
to
8f8d256
Compare
@EmrysMyrddin Can you rebase and make another attempt at this? Maybe you will be able to figure it out now. If not, rebasing would still be helpful for anyone wishing to test and/or continue the work of this PR. |
drivers/unix/file_access_unix.cpp
Outdated
if (real_path != path) { | ||
if (real_path.to_lower() != path.to_lower()) { | ||
// This is a symlink, some platform may not support them. | ||
WARN_PRINT_ONCE_ED("Tried to open a symlink file '" + path + "', referencing to '" + real_path + "' in the filesystem. This file will not open when exported to platforms without symbolic links, like Windows versions before Windows 10."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm using WARN_PRINT_ONCE_ED
because for some reasons, it real spam the console with 17
messages each time I save my script ><'
Do you think I should also change the WARN_PRINT
to WARN_PRINT_ONCE_ED
in the windows version of this check ?
Just printing once won't help IMO, it'll be silent after the first print, until you restart the editor |
It'll be printed once for each file with a case mismatch. |
No it won't be printed once for each, once in total, that's how that macro works, it prints once for each line that has the macro, each invocation |
Does it happen if you do it in another file? This is very weird as the code shouldn't be doing that in this way, worth investigating on its own: godot/core/error/error_macros.h Lines 723 to 731 in e92d55b
|
Todo:
|
@AThousandShips You are totally right, I've used my 2 test files, but each are not triggering the same path. One warns about case mismatch, the other warns about symlinks. So yeah, it only warns once... I will revert to the @fire I'm not sure if this "open 17 times" thing is in the scope of this PR. Seems like a seperate issue for me, like an optimization issue or something ? |
4d2816a
to
d4ce467
Compare
I'm removing the warning for symlinks. They are now supported by pretty much all systems (since windows 10). And I got some people saying they are actually using them to easily share addons between projects. |
This is now probably ready :-) I think the multiple opening files should be addressed in an other PR if it's not an intended behaviour. |
Since it's ready, can you squash your git commits? https://docs.godotengine.org/en/stable/contributing/workflow/pr_workflow.html |
@AThousandShips I think there are some code style issues; what do you think? |
Will do a pass tomorrow! |
@EmrysMyrddin is it ok if I edit your branch? I can also make a new pr. |
I have made a salvaging pull request #98927 |
Of course yes you can make any edit you need :-) |
Ho you already made another PR, do you still want me to squash commits and make the required changes ? |
When a file is opened with a wrong case, it can work on the developer system but but break on a user system with a casesensitive filesystem. This will display a warning when it happens. CAVEATS : It will also display the warning if a symlink is present somewhere in the path. Fixes godotengine#23441 adapt warning if file is symlink fix memory leak and avoid `lstat` usage do not expose real_path when not in TOOLS_ENABLED mode Update drivers/unix/file_access_unix.cpp Don't warn on symlinks
7b905eb
to
78e95d5
Compare
Ok, I've rebased and squash anyway :-) Bu feel free to do whatever is better for you |
Closed in favor of #98927 |
Purpose
This pull request aims to fix #23441 (display a warning when using a file with the wrong case).
Exemples
This shows this warning :
Caveats
Since I'm using POSIX
realpath
function, this warning will also be displayed if there is a symlink somewhere in the path. This is due toreal_path
resolving all symlinks to find a real path on the disk.Exemple:
Here, given that
linked
folder is a symlink, we will get this warning :I haven't found any way to avoid this problem... So if anyone have an idea...