twinejs
twinejs copied to clipboard
2.3+ Backups of a symlinked story folder no longer work (OSX)
Describe the bug.
Apologies in advance for the vague nature of this bug report, since the breaking changes to the 2.4 Backups make it hard to investigate.
In my Twine setup the Stories directory inside the Twine directory is a symlink (against the specific instructions given in the manual, I know the dangers). Up until some point (I think April this year, but this may just be because older Backups were removed, not because it stopped working at that moment) this caused no problems for backups, which were created as full directories with the contents of the Stories directory.
After that point, however, the Backups became copies o the symlink, i.e. they were also symlinks pointing to the same live Stories directory, rather than actual backups.
Steps to reproduce:
As far as I can see, just install 2.3.x and make the Stories directory into a symlink. My issue was on OSX, but I assume any *nix system using symlinks would have the same problem.
Expected behavior:
Backups should be created from the contents of the Stories directory, not of the directory itself.
Additional context on this problem.
I'm quite well aware that this may fall into the context of "Won't fix, you were told not to do it", but I thought it would be useful to report the behaviour nevertheless.
Twine version number
2.3.x
Does this problem occur with the web version of Twine or the desktop app?
Desktop app
What operating system does this problem occur on?
macOS
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.
Just clarifying, symlink as in ln -s
or aliases that you can create in the Finder?
That's a good question. The finder reports it as an "alias" but a quick test shows that it also reports a new symlink I make with ln -s
as an "alias" so that tells me nothing. The shell reports it as:
lrwxr-xr-x 1 username staff 39B 6 Dec 2021 Stories -> /Users/username/Dropbox/Twine/Stories/
Some more testing shows that actual aliases have a larger size on disk than a symlink, so I suspect the answer is: "actual symlink"
Have installed 2.4.1 and can confirm that backups are once again just copies of the alias/symlink
OK, thanks for details. I think it's probably caused by Twine now copying the folder itself vs trying to copy files in it one-by-one. (implementation here, it uses copy from the fs-extra package)
I'd prefer to not write my own implementation of a directory copy if we can at all avoid it, so if there's an alternate library we can use, I'm open to the concept... though fs-extra is battle-tested.
I note that the docs you linked have the following option:
dereference <boolean>: dereference symlinks, default is false
Maybe just set dereference to true?