Tiddlywiki did not save new tiddlers to disk for days, when I noticed it was too late

148 views
Skip to first unread message

Enrico

unread,
Jun 28, 2020, 8:47:44 AM6/28/20
to TiddlyWiki
Hi,
I am writing to figure out whether I could have done something to prevent this pretty bad data loss into which I incurred yesterday, so it does not happen again.

My tiddlywiki setup
I run the node.js tiddlywiki5 as a systemd service on a virtual private server.
It's served from a public IP address (protected by username/password login).
Apache webserver acts as a proxy between the outside world and the `tiddlywiki --serve` process.
`tiddlywiki -version` prints "5.1.22".

What happened
Some days ago I copied over some tiddlers from another tiddlywiki, restarted the tiddlywiki service, checked that I could access old as well as new tiddlers, and happily went along with my life.
At some point, the server process started printing errors that I absolutely did not notice (100% my fault for not checking my server logs for a few days).
Here's the error message that was printed in a loop, always about the "Eye Divers" tiddler:

   vultr.guest tiddlywiki[22081]:  syncer-server-filesystem: Dispatching 'save' task: Eye Divers 
   vultr.guest tiddlywiki[22081]: Sync error while processing save of 'Eye Divers': Error: EACCES: permission denied, open '/home/tiddlywikirunner/tiddlyme/tiddlers/Eye Divers.tid'                   

When I finally noticed these errors, yesterday, I copied the content of the "Eye Divers" tiddler to my clipboard and restarted the tiddlywiki service.
Result: all tiddlers that I have created in the past few days have been lost. It turns out that the problem with the "Eye Divers" tiddler prevented the tiddlywiki process from saving any new tiddler to disk.

The problem
The main problem is that I had no way to know that all those tiddlers were never saved to disk:
  • the browser interface displayed no error whatsoever
  • the icon that shows "Status of synchronization with the server" displayed everything was fine, and lit up every time I edited or created a new tiddler
  • the error message printed by the tiddlywiki server only referred to a specific tiddler, that I took care to copy somewhere else before restarting the server
To me it seems like I really had no way to know that restarting the tiddlywiki server would have caused such a dramatic data loss.
Even if I had noticed earlier, was there any way to "force" the tiddlywiki process to flush to disk all tiddlers that were created and that were in the process' memory only?

Any suggestion is appreciated, I like tiddlywiki but I need things to be reliably synced to the disk that I back up nightly.
Cheers,
Enrico

Mark S.

unread,
Jun 28, 2020, 9:20:13 AM6/28/20
to TiddlyWiki

That's always sad when it happens! Sorry for your loss!

I'm no expert on networking things -- I'm sure someone with more experience will be along.

Ordinarily when you get errors under node a big yellow error message will pop up on screen. My guess is that using apache as a proxy blocked those messages. That is, apache got the messages but didn't pass them to the browser. That suggests there might be some tweaking of the apache proxy that is required. Hopefully someone with experience with apache can help.

If you had noticed before shutting down the server, you could have saved your changes. Use the advanced search, filter tab and type

   [haschanged[]]

Then use the download icon to save all the tiddlers to your local file system in a JSON file. Later, when the problem is fixed, drag and drop the JSON file back into your server.

Good luck!

TW Tones

unread,
Jun 28, 2020, 9:50:17 AM6/28/20
to TiddlyWiki
Enrico

I too am sorry for your loss. If its any consolation this kind of issue is increasingly rare.

I am not exactly sure yet, but if you had the local storage plugin running it may have provided another get out of jail free card. Althought there are plenty of caviets.

regards
Tony

Enrico

unread,
Jun 28, 2020, 10:34:03 AM6/28/20
to TiddlyWiki
Hi,
thank you for the [haschanged[]] + download tip, that would have helped had I known that more than one tiddler was affected.

I do get the yellow pop-ups, usually, e.g. in case of connection errors. I don't think there was a pop-up for this.

Thanks,
Enrico

Rob Hoelz

unread,
Jun 28, 2020, 5:58:39 PM6/28/20
to TiddlyWiki
I'm really sorry to hear that Enrico - that sucks.

For what it's worth, I was able to reproduce this with TiddlyWiki 5.1.22 without a server like Apache or Nginx in front of TiddlyWiki:

$ npm install tiddlywiki@latest
$
./node_modules/.bin/tiddlywiki --version
5.1.22
$
./node_modules/.bin/tiddlywiki wiki --init server
Copied edition 'server' to wiki
$
./node_modules/.bin/tiddlywiki wiki --listen port=9091
$ cat tw
.log
 syncer
-server-filesystem: Dispatching 'save' task: $:/StoryList
Serving on http:/
/127.0.0.1:9091
(press ctrl-C to exit)
$ curl
-s -w "%{http_code}\n" -H 'X-Requested-With: TiddlyWiki' -X PUT -d '{"title":"test1","text":"abc123"}' http://localhost:9091/recipes/default/tiddlers/test1
204
$ cat wiki
/tiddlers/test1.tid
created
: 20200628215555511
modified
: 20200628215555511
title
: test1

abc123
$ curl
-s -w "%{http_code}\n" -H 'X-Requested-With: TiddlyWiki' -X PUT -d '{"title":"test2","text":"def456"}' http://localhost:9091/recipes/default/tiddlers/test2
204
$ cat wiki
/tiddlers/test2.tid
created
: 20200628215557534
modified
: 20200628215557534
title
: test2

def456
$ chmod
400 wiki/tiddlers/test1.tid
$ curl
-s -w "%{http_code}\n" -H 'X-Requested-With: TiddlyWiki' -X PUT -d '{"title":"test1","text":"abc123\n\nupdate"}' http://localhost:9091/recipes/default/tiddlers/test1
204
$ curl
-s -w "%{http_code}\n" -H 'X-Requested-With: TiddlyWiki' -X PUT -d '{"title":"test2","text":"ghi789"}' http://localhost:9091/recipes/default/tiddlers/test2
204
$ cat tw
.log
 syncer
-server-filesystem: Dispatching 'save' task: $:/StoryList
Serving on http:/
/127.0.0.1:9091
(press ctrl-C to exit)
 syncer
-server-filesystem: Dispatching 'save' task: test1
 syncer
-server-filesystem: Dispatching 'save' task: test2
 syncer
-server-filesystem: Dispatching 'save' task: test1
Sync error while processing save of 'test1': Error: EACCES: permission denied, open '/tmp/tw-test/wiki/tiddlers/test1.tid'
 syncer
-server-filesystem: Dispatching 'save' task: test1
Sync error while processing save of 'test1': Error: EACCES: permission denied, open '/tmp/tw-test/wiki/tiddlers/test1.tid'
 syncer
-server-filesystem: Dispatching 'save' task: test1
$ cat wiki
/tiddlers/test2.tid
created
: 20200628215557534
modified
: 20200628215557534
title
: test2

def456
$ cat wiki
/tiddlers/test1.tid
created
: 20200628215555511
modified
: 20200628215555511
title
: test1

abc123



I think what happened is that Node accepts the change and puts it on an in-memory queue for saving, but it fails to process the queue.  Since it accepted the change from the browser, the browser things everything is fine, so it doesn't show the traditional popup, and haschanged[] will come up empty.

I'm going to try to reproduce this with Git HEAD, and see if I can submit a fix for Jeremy to look at.

-Rob

Rob Hoelz

unread,
Jun 28, 2020, 6:10:40 PM6/28/20
to TiddlyWiki
Reproduced on Git HEAD, and reported here: https://github.com/Jermolene/TiddlyWiki5/issues/4742

Enrico

unread,
Jun 29, 2020, 3:46:53 AM6/29/20
to TiddlyWiki
Thank you for taking the time to disentangle and corroborate the buggy/undesirable behavior from my report!

Cheers,
Enrico

Xavier Roy

unread,
Jun 29, 2020, 11:19:16 AM6/29/20
to TiddlyWiki
I had a similar issue when i used Nativefier (https://github.com/jiahaog/nativefier) to create a standalone desktop app. I was trying to create an app from a TW that was online.  Luckily I noticed that the saves were not stored when I closed the app. 

20:48, 29th June 2020: Update: This approach has some issues. When the app is reopened after closing, the data is lost. Not sure where the problem is. Is it due to the save plugin or issue with data storage. I stopped using the app-ified wiki till i figure it out. I use either Firefox or Chrome to use the worklog.

I discovered Nativefier, a command-line tool to easily create a desktop application for any web site using Electron. I ran that tool to generate a Windows app. I also picked up an worklog icon from Iconfinder to make it more app-like.~


Though I am not sure if this is related to the issue that you had mentioned. I just hope some tries this and figures out the reason.

I then switched over to TIddlyDesktop and moved my worklog offfline.

Regrads,
Xavier

TW Tones

unread,
Jun 29, 2020, 8:23:19 PM6/29/20
to TiddlyWiki
Folks,

Just a Quick word on saving and changes within your browser. Even without the local storage plugin active your changes often remain in the browser tabs memory until you close the tab or browser. If in doubt use an emergency saver and you can import the tiddlers back in later. However some tiddlers that change should not be re-imported as they are created by server processes not you, the interactive user. If I know I only edited a few tiddlers I sometimes just drag and drop them on a separate "scratch wiki", a copy of empty.html the I can reload the tab/browser. One approach is to set the usernames and export only tiddlers that were modified by your user name.

One area that is a little less intuitive for people is the space and memory requirements. This has a remedy if you are a big tiddlywiki user as "90% of the Day 90% of my work" is done in various tiddlywikis, many in chrome and Firefox. This means my key applications are browsers, rather than native apps.

Browsers are often designed to be the browser on your device, and they limit their total memory consumption so as to not overwhelm memory and slow you local apps. From memory Chrome and FireFox manage their RAM within 2GB limits by default. On my 16GB desktop I would thus be using two browsers and only 4GB of my available ram all day. With almost 12Gb unused. They were hard to find, and I have lost them since but you can increase the browsers RAM usage limit for performance gains if you are a big browser user, which you are if you are a big tiddlywiki user. Both my browsers use 4GB + now and performance is great. Also maintaining your local drive to have adequate space remaining, 20%+ is wise so the browser or operating system does not try and recover space by clearing caches etc...

A Lot of people work to actively reduce the RAM and disk their browser uses and the browsers are designed to do this them-self, but big browser users should consider taking the opposite approach and give there browsers a lot of headroom.

Regards
Tony
Reply all
Reply to author
Forward
0 new messages