Hey Allen,
I am working on a hot-reload shader system, were a shader is reloaded whenever a file change is detected. I am keeping a handle to the file open with full sharing for the duration of my app's lifecycle.
With the file in this state, I cannot open the file in 4coder. I can open/modify it in Notepad++ and Atom just fine. 4coder doesn't crash or report to *messages* buffer, just nothing happens.
Tested with 4coder-alpha-4-0-21-super-win-x64 no custom layer.
If I have the file already open in 4coder, then launch my app, I get a valid handle, but updates from 4coder aren't actually applied to the file? Not really sure whats going on. By the way, I am checking for updates by seeing if the "last edit time" has changed.
Just wondering if this is something you think is solvable on your end, you have more experience with file IO than I. If not I can try some other solution like opening/closing a shared read handle every frame (previous working solution), or something more fancy like FindFirstChangeNotification. I'd just like to be able to leave the handle open so I don't have to bandy the file path throughout my codebase.
I am working on a hot-reload shader system, were a shader is reloaded whenever a file change is detected. I am keeping a handle to the file open with full sharing for the duration of my app's lifecycle.
1 | CreateFileA(FilePath, GENERIC_READ, FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE, 0, OPEN_EXISTING, 0, 0); |
With the file in this state, I cannot open the file in 4coder. I can open/modify it in Notepad++ and Atom just fine. 4coder doesn't crash or report to *messages* buffer, just nothing happens.
Tested with 4coder-alpha-4-0-21-super-win-x64 no custom layer.
If I have the file already open in 4coder, then launch my app, I get a valid handle, but updates from 4coder aren't actually applied to the file? Not really sure whats going on. By the way, I am checking for updates by seeing if the "last edit time" has changed.
Just wondering if this is something you think is solvable on your end, you have more experience with file IO than I. If not I can try some other solution like opening/closing a shared read handle every frame (previous working solution), or something more fancy like FindFirstChangeNotification. I'd just like to be able to leave the handle open so I don't have to bandy the file path throughout my codebase.
Edited by James Fulop
on
Update: Using
(no read or write access) works for me! This gives me a handle I can leave open that can check the file time while still playing nice with 4coder.
1 | CreateFileA(FilePath, 0, FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE, 0, OPEN_EXISTING, 0, 0); |
My file opening saving stuff is still really dumb right now. But you happen to be asking about this at a great time. For the next build I was already going to make it handle read only files better, so while I'm doing that I'll get file sharing working too if I can. Thanks for bringing up the idea.
I'm glad you found a solution though. I messed with file sharing when I was looking for the best way of tracking file changes in 4coder and ultimately I didn't like the way it behaved. Although I can't remember why now.
I'm glad you found a solution though. I messed with file sharing when I was looking for the best way of tracking file changes in 4coder and ultimately I didn't like the way it behaved. Although I can't remember why now.
Cool! Yea for detecting a changed file, it seemed like FindFirstNotification was the "right" way to do it, but the API for it was weird. You have to register a file which gives you like a notification handle, then you have to either wait on that handle to return a notification via worker thread or check that notification handle every frame... checking the last write time made more sense to me. Just being pedantic about it.
Yeah I agree the API is tremendously not fun to use. I wanted to just leave the file handles open and check timestamps every frame, because that's really quick and precise, but I just couldn't find a good stable way to do that that played well with everything else.
Hey just letting you know that the workaround I mentioned earlier can still throw a sharing violation error on an infrequent basis. So seems like there is a chance that the write time can get updated before the handle is considered available? I'm not going to be using that system for a little while so I'm just gonna leave it as is for now, but just thought I'd let you know that its not a robust approach.
Just wondering, is file IO any more sane on Linux or Mac?
Just wondering, is file IO any more sane on Linux or Mac?
Its more sane in a way that anybody can overwrite file even if somebody else have opened it. Old file will still be "available" for application to read, but just not visible on disk. But otherwise file I/O is more sane on Windows (overlapped I/O).