Fix updating of closed script files

[Kn1feKillz]

Fix: Add updating of closed script files after changing them in the Replace menu

• Fix Files are not reloaded from disk after replacing matches in Search Result #108960

[arkology]

I suppose the same fix is valid for replacing individual results, right?

[HolonProduction]

• Why do you need an additional vector, if there is already an array tracking changed files?
• Why is this the right place to fix the issue? Wouldn't a solution insideFindInFilesPanel::apply_replaces_in_file make more sense to ensure consistent behaviour?

[Kn1feKillz]

Why do you need an additional vector, if there is already an array tracking changed files?

It was my mistake; I didn't see that PackedArray is also a vector of strings. I thought it was a different container. This needs to be changed.

Why is this the right place to fix the issue? Wouldn't a solution insideFindInFilesPanel::apply_replaces_in_file make more sense to ensure consistent behaviour?

I assumed that this function's callback changes the state of many files, and therefore updating them in the editor should be done after all replacements are complete.

Furthermore, I don't see much of a difference in behavior, as the EditorFileSystem::update_file method delegates to the EditorFileSystem::update_files method, constructing and copying a single-element vector.

[Kn1feKillz]

@HolonProduction
I've updated the pull request based on the comments.

[arkology]

Please restore, it will just make a noise in git history.

[arkology]

And unfortunately, I can still reproduce this bug...

[Kn1feKillz]

And unfortunately, I can still reproduce this bug...

Can you tell me what operating system this bug is reproduced on? I'm using Ubuntu 25.10, and the bug doesn't reproduce on it.

[arkology]

Windows 11 (build 26100) - Single-window, 2 monitors - OpenGL ES 3/ANGLE (Compatibility) - ANGLE (Intel, Intel(R) HD Graphics 620 (0x00005916) Direct3D11 vs_5_0 ps_5_0, D3D11-31.0.101.2115) - Intel(R) Core(TM) i3-7130U CPU @ 2.70GHz (4 threads) - 7.86 GiB memory

[andrea-calligaris]

@Kn1feKillz

I'm using Ubuntu 25.10, and the bug doesn't reproduce on it.

You were able to reproduce it, though?
#114390 (comment)
#108960 (comment)
What changed?

I can reproduce it consistently on Xubuntu 22.04.5 LTS, X11.
Godot v4.6.stable.official

Make sure to:

• First open the file, then close it.
• Only then make the Replace, via Search → "Replace in Files..."
• Reopen the file, and see no changes (old cached file).

[Kn1feKillz]

@Kn1feKillz

I'm using Ubuntu 25.10, and the bug doesn't reproduce on it.

You were able to reproduce it, though? #114390 (comment) #108960 (comment) What changed?

I can reproduce it consistently on Xubuntu 22.04.5 LTS, X11. Godot v4.6.stable.official

Make sure to:

* First open the file, then close it.

* Only then make the Replace, via Search → "Replace in Files..."

* Reopen the file, and see no changes (old cached file).

i cant reproduce this bug with my changes in this PR

[arkology]

Ok, I spend some time trying to figure out why it does now always work on my side (as I wrote before, Windows-based system).
Looks like it is caused by the fact that file (FileAccess) is not closed before updating it using EditorFileSystem. I'm not 100% sure because I don't have much experience with filesystem operations, so I decided just test it.
And after adding f.unref(); between f->store_string(buffer); and EditorFileSystem::get_singleton()->update_file(fpath); I get instant updates in Godot editor (toast notifications after breaking all scripts using replace)!
But this change still needs verification from contributors, more experienced in this area.

[kitbdev]

Makes sense to me that it should be closed first. Though it should use f->close() instead of unref.