twinejs
twinejs copied to clipboard
klembot
Consistent error message when using Windows Symlinks for Stories folder
Describe the bug.
Upon updating to Twine 2.5.1, got error: (EPERM: operation not permitted, symlink "Folder name to Folder name") Hard Sym links were being used to automatically back up stories folder to another place on hard drive (google drive). Error message references twine\Backups although symlink is aimed at stories folder. Stories Symlink was inside of twine folder pointing somewhere else.
Attempting to diagnose problem I deleted symlink, and then recreated it using windows 10 console command (mklink) Did not work with hard or soft symlinks.
Another issue mentions that this is recommended against in a manual I don't know about and couldn't find after searching the internet, so I apologize if this is a bad report.
Steps to reproduce:
Create hard symlink using windows console commands, link is stories folder in twine folder, target is stories folder elsewhere (in this case inside the google drive folder) Start twine 2.5.1 Receive error message
Expected behavior:
Previously system had not given error and files were correct at intended location. This enabled back up to cloud.
Additional context on this problem.
No response
Twine version number
2.5.1
Does this problem occur with the web version of Twine or the desktop app?
Desktop app
What operating system does this problem occur on?
Windows
If this problem is occurring with the web version of Twine, what browser does it occur on?
No response
Presubmission checklist
- [ ] I am interested in working on code that would fix this bug. (This is not required to submit a bug report.)
- [X] I have done a search and believe that an issue does not already exist for this bug in the GitHub repository.
- [X] I have read and agree to abide by this project's Code of Conduct.
I am also using 2.5 with a symlink, but this time on MacOS, and it continues to work fine.
The following issue (https://github.com/electron/electron/issues/11094) suggests that this could be an Electron issue, although that is about creating symlinks. This may be because on opening the app tries to make a backup, and as noted in another conversation, when the story folder is a symlink, the app makes a new symlink to the same destination (instead of copying the contents of the directory).
I'd like to suggest that Twine just let you choose a story folder location, it would make things easier for a all these issues.
Can't repro this myself since I'm on a Mac, but code contributions to address this would be welcome.
And here I throught I was the only one with the error. I hardlinked the Twine Folder to be inside my Dropbox, so we can collaborate on a story.
Every time Twine tries to save it get's an Error thrown.
FYI, putting your story folder in Dropbox will probably cause problems if you ever are editing at the same time as someone else. Twine should warn you when this happens.
FYI, putting your story folder in Dropbox will probably cause problems if you ever are editing at the same time as someone else. Twine should warn you when this happens.
It does. Anecdotally, I've always had my story folder in Dropbox without issues, but I don't usually make changes on two computers at once. However if I modify a file in some other way (e.g. open it in a text editor and do a find and replace), I get the warning and have to restart Twine.
FYI, putting your story folder in Dropbox will probably cause problems if you ever are editing at the same time as someone else. Twine should warn you when this happens.
as we are in seperate timezones that is highly unlikely. and i doubt it's part of this problem/bug.
Twine has a problem with it's folder not being in 'C:\users<user>\documents' and quite frankly I don't understand why it has to be there in the first place
This application is used by many people who are not "software developers" (eg; Authors, Artists, Students, etc..), and in some ways the application can be considered more "Consumer" level in nature than "Developer" related. This nature is partly reaffirmed by the fact that all saving is automatic, which is very unusual in a "Developer" orientated application.
I don't understand why it has to be there in the first place
Many Window's users have limited knowledge about "setting up / configuring" an application and generally expect applications to "just work" out of the box, in the same way a Mobile Device application would. Also it is not unusual for a Windows "Consumer" level application to default the storing of the files its generates within in the user's "Documents" folder. eg. Word Processors, Spreadsheet editors, Image & Audio editors, etc...
What is unusual to some extent is the inability to change at installation the location of the folders (like "Story") that application uses internally.
What is unusual to some extent is the inability to change at installation the location of the folders (like "Story") that application uses internally.
Thank you for rephrasing my sentence.
Otherwiese you perfectly described the de-evolotion of Users. Maybe coming from back when Windows 98 was still a thing thaught me how to 'set up' an "App" (or just call me old). However this is a trend I see in quite a few apps - they just assume you want a out of the box click and forget install. Forcing themself into the /temp/local/ folder.
While the issue here is that twine can't handle mklink / symlinks on windows, the underlying issue is that you can't choose where to save. (wich is #1158 ) it should be moved from P3 to P2 or even P1 - then this issue here, with symlinks wouldn't arise at all.
Yes, Users that want a OotB Experience don't care about where thier files are even located, but if you try to backup/collaborate or otherwise free space on the C drive, the option to change should be avaible.
I think I will downgrade to 2.3.x because there it would at least save to a location, that is not in Documents, if you symlinked it.
I am having similar issues after upgrading from 2.3.x to 2.5.1. Windows user, desktop app. Getting the error reported originally and related errors. I think it is because OneDrive is attempting to sync the Twine story I am editing while I am editing it in Twine. I tried to change the Twine story folder path but there's no way to do that in 2.5.1. I also tried setting the permissions on my temporary internet files folder and Twine folder from read-only to not read-only. I also tried to disable OneDrive backup for the Twine folder that contains Stories and Backups. This hasn't stopped the errors although it seems to have made them less frequent. (This also generates OneDrive error icons in Windows Explorer.)
In terms of dev workflow, the problem is that every time this error occurs (about every 20 minutes), I have to publish my Twine story to file and then reimport it. If I don't do that, Twine cannot find my story after I close and reopen the application.
I have reverted back to Twine 2.3.16 for now.
To echo the comments above, the sym links is only a work around, and being reported as a bug because there is no other work around. It would be nice to be able to change the home folder for twine stories, either during installation or through an option in the program. Alternatively my issue, just mine, could be solved by having a duplicate output folder that I could designate the target for. The read folder can stay the same. I have no idea if this is possible programming wise. I have been working on my current project for several years and the idea of not having it backed up to the cloud and on only a single hard drive makes my skin crawl. Especially because twine isn't great about having multiple versions of the same file, and I'm forgetful about backing up things as is.
and I'm forgetful about backing up things as is.
Thus one reason for the existence of a Task Scheduler :)
Seems like my Issue is reflected here, to syncronize my Story Folder between my Laptop and my PC, i have symlinked the story folder structure to my OneDrive - which was a hassle in ifself. Other Apps let me choose where I want to save my content. But anyways, after I got that symlink working twine keeps deleting my files for no apparent reason. As it stands I seem to have to go to VS plugins to get then TweeGo to run, just because i want to get my creative works done outside my flat - wich is kinda rediculous.
@klembot Would the fact that OneDrive alters a file's timestamp each time its real-time sync feature decides it needs to download the remotely stored copy to replace the local file be affecting the Twine 2.x application's own opinion on what state a project HTML is in.
eg. OneDrive believes it has total real-time control over the current state of any file it is tracking.
It appears that some Electron developers have had a file-lock related issue when opening files that are under OneDrive's control, which may or may not be related.
@greyelf
I've not had this problem with Dropbox, though it should be conceptually the same. It may just be that Dropbox is more well-behaved about not updating files that haven't changed, or by creating conflict files when something has changed. (To my knowledge Dropbox has a checksum of each file, and if the file about to be overwritten has a different checksum from what it it expects, it will create a conflict file instead, preserving the live copy as is).
When I switch between computers, as I do quite often at home, and update Twine files, the Twine app doesn't complain, even though it shows the updated stories. However if I make a change to a file in the stories folder with a text editor, the copy of Twine on that machine will immediately complain and ask to reload — while the copy on a different machine gets the changed file through Dropbox and doesn't complain.
@hituro
Does Dropbox preserve the current timestamp (a) of a tracked file, or does it update that timestamp (a) each time a file is uploaded to and downloaded from the server?
Because (based on the linked information) OneDrive doesn't, which could make version controlling of those files interesting.
(a) potentially both/either the created and/or updated timestamps.
@greyelf
I believe (from spending far more time on the documentation yesterday than I should have) that it preserves the timestamp that led to the update. They stated that the creation and modification time of a newly created file would be the timestamps from the original time, not the time that Dropbox syncs it.
@klembot Would the fact that OneDrive alters a file's timestamp each time its real-time sync feature decides it needs to download the remotely stored copy to replace the local file be affecting the Twine 2.x application's own opinion on what state a project HTML is in.
Here's an explanation of how 2.4 handles this. It worked differently in 2.3. (2.3 did not look at modification dates so far as I can remember--it attempted to lock story files from being modified by external processes while Twine was open, but this didn't work in all cases, especially on Windows, and if Twine crashed, it left things locked.)
- Every time Twine writes to a story file after a user edits it, it records the modification date of the resulting file in a cache in memory.
- On each subsequent time it writes to a file, it checks the file's actual modification date against the one Twine previously recorded.
- If the two are different, then it should be because an external process modified the file. Twine asks the user what they want to do.
- If the two are the same, Twine proceeds with saving and updates the modification date in its records as in the first step.
So... I think if OneDrive or some other process modifies a file while a user is working in Twine, it should pop up an alert dialog in Twine. But if the process leaves the modification date in place, Twine will overwrite that file, which means potentially overwriting someone else's data. But this is all an educated guess. I haven't tested Twine in conjunction with OneDrive or Dropbox or any other sync software.
When Dropbox was asked how they look at the files, they compare 'everytime' a file is modified e.i - everytime twine would autosave. I guess this uploading and versionen creates problems within twine.
But as suggested before hand - make the dictionary the files are saved to selectable so there is no need for symlinks at all.
Well, I think I forgot to link it here. DropBox answered our question on the 'when' they save a new file
https://twitter.com/DropboxSupport/status/1580610155934539776
maybe I asked the wrong question, but nonetheless it think it brings some light into this darkness here
Feel like this issue got off topic a bit. I think the general consensus is that if #1158 was fixed and there was a preference that allowed changing the default auto-save location for Twine, then this issue goes away too, as them symlinks wouldn't be needed, right? Symlinks were just a band-aid around the original problem.
FYI, this and the underlying issue are both in the top-10 of issues with the most comments. And I just saw there's actually an older original issue #477 which is the most up-voted issue.
