Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

todo.txt-file closed *sometimes* after Syncthing updates it #443

Closed
dnngll opened this issue Dec 6, 2022 · 17 comments
Closed

todo.txt-file closed *sometimes* after Syncthing updates it #443

dnngll opened this issue Dec 6, 2022 · 17 comments
Assignees
Labels
bug Something isn't working

Comments

@dnngll
Copy link

dnngll commented Dec 6, 2022

Is it an actual bug?

  • I believe so

Did you check if the bug has already been reported?

  • I did, didn't find anything

Describe the bug

  • Open a todo.txt with sleek
    2022 12 06, 21 01 17

  • Change the content of that file on another machine

  • Syncthing updates the file after a few seconds

  • sleek "closes" the todo.txt-file and shows a warning
    2022 12 06, 21 01 35

  • After reopening, the change will be displayed correctly
    2022 12 06, 21 01 47

  • Happens sometimes, not always

  • Can happen when ticking, unticking or changing a todo with another application

  • I did not try if this also happens when adding or deleting a todo. It should though, see below ("My thoughts")

To Reproduce
Steps to reproduce the behavior:

  • See above

Do you see any error entries in sleeks developer tools?
While sleek is open press Ctrl + Shift + I which will open the developer tools. If the shortcut doesn't work, press the Alt key, select the tab "About" and select the developer tools. In the dev tools select the tab "Console" and check if any error entries are written, while you provoke the bug.

  • The shortcut doesn't work plus I don't have this menu

Expected behavior

  • todo.txt stays opened

Screenshots

  • See above

Desktop (please complete the following information):

  • OS: Win 10 Pro
  • Version of sleek: Tried with both 1.1.9 and 1.3.0
  • Source: Github

My thoughts
I believe, that when Syncthing is overwriting/changing the file, it is missing for a few milliseconds. Since this only happens sometimes, I assume it depends on whether sleek checks for the file in just that moment.

If that's the case, sleek produces the error above. This is the same error when renaming the file - however, the behavior, when renaming it back, is a little bit different.

Thanks :)

@dnngll dnngll added the bug Something isn't working label Dec 6, 2022
@CPUGPU
Copy link

CPUGPU commented Dec 7, 2022

I use Syncthing to sync multiple todo files between two computers and one phone and have not experienced this in the four months I've been using it. It may be a Syncthing setting. I'm using default settings except I use simple versioning on all instances.

@ransome1
Copy link
Owner

ransome1 commented Dec 7, 2022

I use Syncthing to sync multiple todo files between two computers and one phone and have not experienced this in the four months I've been using it. It may be a Syncthing setting. I'm using default settings except I use simple versioning on all instances.

I'm also on this setup and never experienced this issue. But many others have. I remember a couple of bug reports like yours @dnngll.

Can I ask you if you are working on a rather slower computer or are you connected to a slow internet connection?

I believe Syncthing's actual syncing mechanism removes the file for a split second and replaces it with the new one. In that split second sleek's file watcher does its magic and if it is doing this too fast, it won't find the new file, which by then is still in creation by Syncthing.

What we can do (and actually already did on the past. I don't know why we removed it) is to add a timer into sleek. So when a file change is detected by the filewatcher, we wait for 100ms and only then continue working on that file. Within those 100ms, Syncthing should be able to replace the file.

Let me see, if I can come up with a quick prototype tomorrow to test it. @dnngll can you precisely reproduce the issue on your computer? We would need to hold your version against a pre-release sometime tomorrow.

@ransome1
Copy link
Owner

ransome1 commented Dec 8, 2022

@dnngll can I ask you to check out this pre-release and tell me if thhis changes anything on your side? https://github.com/ransome1/sleek/releases/tag/v1.3.1-rc.2

I changed the way the file watcher works and added a 100ms interval. Maybe this already solves the issue. Otherwise we continue working this out.

@dnngll
Copy link
Author

dnngll commented Dec 9, 2022

Hi @ransome1 ,

thanks for another super-quick-fix! I'm still not using sleek as my main tool, due to the (yet) not able to fix #68 . Which is probably why I didn't find that bug sooner.

To answer your questions:

Can I ask you if you are working on a rather slower computer or are you connected to a slow internet connection?

Hardware

  • My current main machine is a Thinkpad Nano Gen 1 (20un002uge), the original SSD was replaced with a Sabrent 2242 M.2 NVMe SSD 2TB. The system is set up and tweaked to maximum performance -> shouldn't be the bottleneck

Internet

Fix

What we can do (and actually already did on the past. I don't know why we removed it) is to add a timer into sleek. So when a file change is detected by the filewatcher, we wait for 100ms and only then continue working on that file. Within those 100ms, Syncthing should be able to replace the file.

Yeah, I was thinking something similar. Like, for the first 500ms that the file is not available, grey out the text and wait, before finally producing the "File not found"-error...

Update

Will test that now and get back to you after!

Thanks again :)

@dnngll
Copy link
Author

dnngll commented Dec 9, 2022

Okay then,

I used https://github.com/ransome1/sleek/releases/download/v1.3.1-rc.2/sleek-1.3.1-rc.2-win.zip and it seems to be working. Not one issue with sleek "loosing" the file, I tried 14 times:

2022 12 09, 10 24 13

You are a a Gentleman and a Scholar! Waiting for #68 is getting harder and harder 😂

Thanks again!

@ransome1
Copy link
Owner

ransome1 commented Dec 9, 2022

Wonderful, then this will be released kn 1.3.1.

As for #68 I myself can't wait to implement it ;) But we're still waiting for upstream.

@durgaswaroop
Copy link

It's good if this is already fixed as part of that PR.
But just to add, I have seen this happen even when I modify the file outside sleek.
A lot of times, I open the todo.txt file on VS Code to edit multiple to-dos at once. And I often see that, when I hist save in VS Code, while sleek is open, the entire list of to-dos disappear.

I don't if it is the same case with VScode as well (deleting and recreating), but I will also try to see if the new version fixes that.

@github-actions
Copy link

This is an automated response. We acknowledge your report, and we appreciate your engagement. However, as there has been no recent activity in this thread, it has been marked as stale. If you have any further feedback or if the matter is still relevant, please do not hesitate to respond. Otherwise, this thread will be automatically closed in 15 days from now.

@jbtodo
Copy link

jbtodo commented Jul 20, 2023

Not sure if commenting will reopen this, if not, I'll open a new issue next week.
I am on Sleek 1.3.1 and sync with Dropbox and get this same error when I edit the todo.txt on a different device.
This is mostly frustrating as I have to navigate into folders to open the file each time, if there is a way to have a default location, that would certainly help.
Thanks!

@CPUGPU
Copy link

CPUGPU commented Jul 20, 2023

It may no longer be relevant as ransome1 is completely rewriting sleek:
#501

You may want to try out the 2.0 development branch and see if the issue still exists. Though fair warning: It's not production ready. You would want to have test/duplicate todo files to test.
https://github.com/ransome1/sleek/discussions/503

@jbtodo
Copy link

jbtodo commented Jul 21, 2023

I'll live with it until 2.0 then, thanks!

@ransome1
Copy link
Owner

@jbtodo have you tried using the developer preview and checked if the issue still occurs?

@jbtodo
Copy link

jbtodo commented Jul 21, 2023

I have not yet, I'll think about that and might give it a whirl. Thanks

@ransome1
Copy link
Owner

@jbtodo have you had the chance to check it out? Here is the link in case you want to look into it: https://github.com/ransome1/sleek/releases/tag/v2.0.0-dev7

@jbtodo
Copy link

jbtodo commented Sep 4, 2023

I did, it looks good and not having sync issues with a couple of tests from difference computers and my phone. I assume all the features haven't made it over yet, there is only one setting in the settings dialog, cannot find dark mode, etc.
I also really l like being able to edit due date and threshold without opening/saving the item.
Thanks!

@jbtodo have you had the chance to check it out? Here is the link in case you want to look into it: https://github.com/ransome1/sleek/releases/tag/v2.0.0-dev7

@lrq3000
Copy link

lrq3000 commented Sep 14, 2023

I experience the same issue using Syncthing and Sleek v1.3.1, but it does not happen all the time. I discovered sleek with v1.3.1 so I have no reference point other than that but the 1st time I ured it I had the error as described above, then 2nd time another day same "file not found on disk" error but this time sleek did not close but reload correctly despite the error and the 3rd time i got no error at all and the file was synced correctly.

To be more specific about my setup, i use sleek on a win11 pro machine, and in parallel i use simpletask + markor on an Android phone. It's when I edit the todo.txt on my Android phone and then use Syncthing to sync that the issue happens randomly. When it's a heisenbug like that, usually the randomness stems from I/O variable latency, so the hypothesis of network latency being the culprit seems reasonable.

I did not yet test the 2.0 rewrite, I'll do once there is a dark mode implemented.

And many thanks for the great app, it's hands down the best todo.txt gui on desktop oses!

For reference, crosslinking #155 which seems to stem from same culprit.

@ransome1
Copy link
Owner

if this still occus in 2.0, feel free to re-open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants