SDSL Compilation error, can't find file or dependency, randomly happening

pakreht · March 30, 2026, 1:39pm

Hello people, just wanted to share a horror story that I’ve been living in for the last year •ᴗ•

I’ve had .sdsl compilation errors since I’ve started using VVVV. When I save a shader I get an error on VVVV where it either tells me that it can’t find the shader anymore or that a dependency can’t be found, while it was able to find it just before.. always happened at random times, no visible pattern, never able to reproduce it by doing the same thing twice..

Happened very often, took the habit of restarting VVVV because there was no other way to get the shader working after an error like this.

But today, I seem to have had a reliable one, I could reproduce it every time, just adding a random comment to my code triggered it ! So I thought perfect, finally a setup I can share for debug on the forum, so I reproduced a minimal version of it with the intent of sharing it here. The setup is done, it can be reproduced still, get ready to send it here.

As a good debugger habit, I thought I would remove any doubt that it could come from anything else than VVVV. So I closed VSCode and started doing the same modification & saving but this time in the basic Windows Text editor (Notepad), and then .. nothing, there is no compilation error anymore ..

Did this 3/4 times in a row :

Add random comments and save multiple times in VSCode → get error after 2/3 saves
Same thing in default text editor → Not a single error, after ~40 modifications & saves

Did it back and forth and got the bugs reliably using VSCode, never with default text editor.

This is crazy to think that all this time it’s been my code editor which may have been the issue, maybe related to it locking the file for a microsecond sometimes while Stride needs it ??

Well, at least I’m relieved now, after almost a year of this lol.

pakreht · March 30, 2026, 8:49pm

After some research, my theory would be that it’s related to this VSCode issue which seems unsolved since 2023:

github.com/microsoft/vscode

Allow to disable atomic writes for user data

opened 06:39AM - 13 Oct 23 UTC

ElectricRCAircraftGuy

feature-request config file-io

Does this issue occur when all extensions are disabled?: **yes** - VS Cod…e Version: 1.83.1 - OS Version: Ubuntu 22.04 Steps to Reproduce: At a minimum, this issue applies to these two really important files I normally have as symlinks to point into my repo: ``` ~/.config/Code/User/keybindings.json .config/Code/User/settings.json ``` 1. In a terminal, run `watch -n 0.5 ls -li ~/.config/Code/User/settings.json` to begin watching the inode number of the settings file. The inode number is the number at the start of the line. This command checks the inode number every 0.5 seconds. If the inode number changes, it means the file cannot be tracked by other programs, because the file was destroyed and recreated entirely, with a new inode number. 2. Open VSCode. 3. Press Ctrl + P to open the command palette. Search for `Preferences: Open User Settings (JSON)`. Open it. Press Ctrl + S to save the settings file. You don't need to change anything. Just press Ctrl + S. This triggers a settings file save, and instead of just updating the file in-place like a normal program would do, or like VSCode *used to* do, it wipes the file and creates a whole new inode number! This means there is now no way for me to either symlink *or* hardlink to the settings files to back them up in my git repo like I've been doing. Both types of links get wiped by the save function in VSCode since it's wiping the settings file and creating a new one with an entirely new inode number.

The only thing that bothers me is why would this only concern me? Never saw anyone mention this issue before, and @tonfilm made a plugin for VSCode so I would expect more people being concerned here. Is there anyone else:

Often writing .hlsl
Using VSCode
On Windows 10

These are the only points which I think may matter in this bug.
Also I disabled all plugins to be sure it wasn’t coming from any.

Thanks for the help.

pakreht · March 30, 2026, 9:38pm

Update, same bug with Sublime Text as in VSCode. Still never happened in default Windows Notepad. I’ve tried :

Testing in a location without cloud sync
Added the path to Windows Defender exclusion
Disabled VSCode Watcher (Watcher Exclude : **/*.sdsl)

Still the same issue. I can share a small contained project with the .sdsl causing the issue on save if needed.

antokhio · March 31, 2026, 7:38am

This might be a system related, never had issues with vscode. Might be that you have something installed on machine. To be clear steps to reproduce:

create shader
edit/save vscode or sublime 3-4 times
should see error?

Elias · March 31, 2026, 10:53am

Hm, sad to hear, never ran into this issue you describe but feel free to share the project / repro case you have. Maybe we get lucky.

pakreht · March 31, 2026, 11:31am

Tested the exact same setup on a second computer I’ve had, no issue whatsoever
This is definitely coming from my main PC only, will have to dig alone on this one

Just installed Procmon to try to understand all this

Thanks for the support <3

pakreht · March 31, 2026, 1:43pm

I may have found the issue, and a modificaton on Stride may be able to solve it.
Let me explain.

Using Windows Process Monitor, i was able to track every processes interacting with the .sdsl file, and understand all scenarios.

Scenario A : Everything work

VSCode lock the file and do modifications, then release it. Just after VVVV catch it, and do its things. Success.
Important to note, VSCode keeped the file for 0.08s.

Scenario B : Conflict, but work

Here we can see that VSCode is starting to interact with the file, and he haven’t finished yet but VVVV is allready trying to do its things too. VVVV encounter SHARING VIOLATION multiple times but try again and then end up having access to the file and is able to do its thing without any further issues.
VSCode was on the file for almost 0.5s (yes thats big).

Scenario C : Conflict, lead to error

Same thing as in Scenario B, but after VVVV have tryed 20 time interacting with the file without success due to SHARING VIOLATION, it gave up and cause the error on VVVV.
In this case VSCode keeped the file for 0.6s.

The error caused VVVV side :

Conclusion

Yes my VSCode keep the file for a while when saving (~0.5s).
I have done a fresh install, no pluggin, closed a bunch of background app, but still.
Issue is probably related to my aging computer, the ammount of dust in it, and the fact that almost all my disk are 95% filled, or even some hidden crypto miners, who know.

In the end, the way VVVV handle this isn’t good either : it try to access the file for 0.5s and if he can’t, no matter the reason he just assume the file do not exist, while in our case its due to SHARING VIOLATION, which mean the file is Locked by something else, not lost.

Maybe VVVV could consider this special case of a file being locked for too much time, and retry in a second without making VVVV error.
The nasty thing about this error is that when it happen, the file isn’t tracked anymore because its considered lost, so no further modification will make the error go away, you have to restart VVVV.

Thanks for your help •ᴗ•

Elias · March 31, 2026, 3:46pm

Great insight thanks! I looked at the code briefly and there are two file watchers in place. One we have our under control and it kicks in with a 500ms delay. I think we can increase that number and also add a throttle operator to ensure there’s silence on disk before trying to read.
The second watcher and my guess this is the one troubling you is in the effect system of stride itself and modifying that one will be a longer undertaking. That one kicks in immediately there’s no delay what I can see. It invalidates the shader file and I think reads it again in the next Update call. So you could try making your edits in stopped state and see if the issue goes away?

pakreht · March 31, 2026, 9:37pm

Based on your input + a test i’ve just done it may come from the file watcher you have under control !

I paused VVVV (F6) and did the same thing with VSCode + Process Monitor, i was able to reproduce the same issue, with the node showing the error “Unable to find the file [shaders/Shatters_FL_DrawFX.sdsl]” while VVVV is still paused.

So it should come from the file watcher that kicks in after 500ms, and this would match with my previous observation that the treshold is 0.5s.

(VVVV was paused during the whole process and the node switched to the error red version while VVVV was still paused).

Elias · April 1, 2026, 5:04pm

You’ll find a new setting “File watcher delay” in upcoming preview build (7.2-21) which allows you to change the time after which the system reacts to file changes.

(After changing the setting you will have to save a shader file one additional time for the change to take effect)

pakreht · April 1, 2026, 7:25pm

Cool thanks !

Also for the future don’t you think a more adaptive system could be better ?
Something like a “throttle operator to ensure there’s silence on disk before trying to read” like you mention earlier.

Thanks again for the quick modification

Elias · April 2, 2026, 7:07am

I forgot to mention, that silence period is in there as well now.