-
-
Notifications
You must be signed in to change notification settings - Fork 21k
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
Prevent overriding file info of another file when reimport creates extra files #85922
Prevent overriding file info of another file when reimport creates extra files #85922
Conversation
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.
The issue is confusing to reproduce and the fix is not obvious. I'd add a comment next to the new _find_file()
explaining why is it called.
Other than that looks ok.
747150e
to
69e7fcf
Compare
Thanks! I've just added the comment. |
@KoBeWi Every time I was trying to do something with Godot 4.x (personal projects, game jams etc.), I was always reaching the point where random scenes were getting corrupted. It was a constant thing for me especially in the 3D projects. I was trying to fix scenes with the "Fix dependency" but there never was any error. After long investigation of this issue (with the huge help of @gonzelvis) we were able to found the exact source of those problems and 100% working repro steps that could lead into corrupted scenes (and more). In short.. this PR fixes problem which indirectly could cause:
I don't have time to examine it further, but after what I learnt when I was investigating this bug I think this probably fixes the following issues (you can see most of those issues are related to glTF and/or MeshInstance3D): Those above would be worth to check first but there might be the chance this also can fix some of those issues: And for testing purposes, the easiest repro steps for the bug, that this PR is fixing, are the following:
Now using such corrupted mesh with duplicated UID anywhere will lead to many different problems like corrupting scenes. |
69e7fcf
to
aae48ac
Compare
@MetRiko I checked these issues and was able to confirm 2 more that this PR fixes (already added them in the OP). I also closed 2 issues as already resolved/duplicate. |
Thanks! Great work tracking this down 🥇 |
That's exactly what I meant by:
and by
This will not fix directly problems caused by duplicated UIDs but will prevent UID's duplication. There is no reason in "fixing" bugs caused by using resources with duplicated UIDs because engine is not even suppose to have duplicated UIDs anywhere at all. Each resource should always have one unique UID right? So there is no point in fixing those anomalies, however it would be nice to have at least a good readable error/message that will point out duplicated UIDs and how to fix it. |
Wow!! Thanks for fixing this! I think you and I may have discovered the problem independently around the same time, Wednesday last week. If I had submitted my discovery as a pull request, it might have saved you the time of doing this. Based on my diagnosis/understanding, this fix is correct. The issue only affected files beginning with the letters "r" through "z" due to another problem in EditorFileSystem where it tries to keep directories sorted, but compares all strings against the full path starting with "res://", so most files were simply appended to the end of the directory, which would then not affect the
What happens if the user manually copies and pastes a file elsewhere in the project, and this file has a particular UID embedded in its .res header? |
Let's say you have file Entity.tscn and you will create EntityCopy.tscn by duplicating it outside Godot editor (in OS file explorer or with commands). In that case Entity.tscn and EntityCopy.tscn will have the same UID. Now if you will:
then EntityCopy.tscn will get the same UID as before (still duplicated). However if you will:
then new UID for EntityCopy.tscn will be generated. For the references.. let's say you used EntityCopy.tscn inside World.tscn.
(where I think this should be raised as a separated issue/proposal. |
Cherry-picked for 4.2.2. |
Cherry-picked for 4.1.4. |
Fixes #80132, fixes #75525, fixes #77978, fixes #83154
Special thanks to @MetRiko and @gonzelvis for helping me figure out the exact repro steps. They had issues with
*.glb
files and repro turned out to be exactly the same as in #80132.EditorFileSystem::_reimport_file
calls_find_file(p_file, &fs, cpos)
to get the file index infilesystem
(fs
). The problem is - if reimport creates extra fiiles, thefilesystem
gets invalidated and the next usage ofcpos
is incorrect -_reimport_file
updates wrong file info leading to duplicated uid, dependencies etc. The uid inside created file is still correct at this point, but the data infs->files[cpos]
is invalid, so saving the scene after assigning the affected resource causes the resource to save with wrong uid.Adding
_find_file(p_file, &fs, cpos)
just before the next line withcpos
refreshes thecpos
index so now it points to a proper file infs->files
.