This doesn’t directly relate to Twine, but it significantly affects how I use it. I am wondering if anyone’s come across this problem:
Local html files opened in Chrome are sometimes (and only sometimes) treated like file types that are open in other apps, where Windows will prevent you from deleting them (“This action can’t be completed because the file is open in Google Chrome.”).
Since Twine doesn’t tell you when it can’t overwrite a file, it leads me to situations where Chrome decides to not let it update the file, and I’m hitting refresh to see if some bug or issue is fixed and nothing has changed. It’s annoying.
The file won’t delete even if I close the tab the html file is open in and/or delete it manually in Windows Explorer. I have to shut down all the browser windows and wait a minute, then delete it.
Anyone had this? I don’t see why C would deny access to a file, it’s only supposed to read them, not write to them.
Just to be clear, when you talk about the “Local html files opened in Chrome”, you mean opened in Twine running on the Chrome browser, correct? If so, it sounds like the file isn’t properly closed after it’s been read, which can have the same effect of locking the file open, which prevents it from being able to be deleted.
I’d recommend reporting the issue at the Twine issues tracker page here, along with mentioning which OS you’re using and any steps which seem to reliably trigger this problem. You might also want to open the browser’s “Developer Tools” and look in the console window to see if you see any errors reported there.
I mean the following: I am running the installable version of Twine on my Windows computer. The file that I publish to for testing resides in a local folder. I have it open in Chrome for testing. I’m not sure if that’s what you meant with your wording.
In trying to create a reproducible scenario to report on the Twine end of the issue (failing to inform you that publishing failed because a file cannot be overwritten) I realized this only occurs when the browser lays claim to the file, but not when I manually write protect it.
For the Chrome side, I’ve been playing around and can’t seem to figure out what triggers it. Shutting down the Twine app doesn’t seem to do anything (I’m not sure if it runs an instance of Chrome inside itself or something like that). Right now I’m experimenting with testing the game in an incognito window, but because of the unpredictability of the issue I won’t know if this makes a difference for a while.
Modern Twine story HTML files generally use your web-browser’s Local Storage cache to store the story’s progress data as well as any Saves created by the Reader.
This means that you can’t use a Privacy Mode (like Chrome’s Incognito) to view the contents of a story HTML file, nor can you view it with Cookies disabled, because both of these options disable the Local Storage cache.