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

Creating new entries with multiple simultaneous jrnl processes overwrites journal #1106

Open
wtraylor opened this issue Dec 11, 2020 · 1 comment
Labels
bug Something isn't working major Has potential for data loss 📌 This can't go stale

Comments

@wtraylor
Copy link

Bug Report

Environment

jrnl: v2.5
Python: 3.9.0 (default, Oct  7 2020, 23:09:01)
[GCC 10.2.0]
OS: Linux 5.9.12-arch1-1

Installed through Archlinux package community/jrnl.

Current Behavior

When creating two simultaneous editor windows by calling jrnl and closing them one after the other, only the entry from the window that was closed last will be added to the journal file. The other entry is lost.

Expected Behavior

Both entries are added to the journal file.

Repro Steps

Config file:

editor: vim
journals:
  default: /home/living/jrnl.txt
  1. Call jrnl. The editor (Vim) opens. Type "closed last", but don’t close the editor.
  2. Call jrnl again in another terminal window. A second instance of Vim opens. Type "closed first".
  3. Close the second editor session. Jrnl prints [Entry added to default journal]
  4. Close the first editor session. Jrnl prints [Journal 'default' created at /home/living/jrnl.txt] [Entry added to default journal]

Now, jrnl.txt only contains the entry “closed last”. The other entry is lost.

This happens also with existing journal files, not only with a newly created one as described above.

@wtraylor wtraylor added 🆕 New! bug Something isn't working labels Dec 11, 2020
@micahellison micahellison changed the title Entries lost with multiple simultaneous editor sessions Creating new entries with multiple simultaneous jrnl processes overwrites journal Dec 12, 2020
@wren wren added 📌 This can't go stale and removed 🆕 New! labels Dec 12, 2020
@wren
Copy link
Member

wren commented Dec 12, 2020

Thank you for filing this!

It looks like this was a regression caused by #799 .

The fix for this issue without regressing #799 is to move the password prompt back. We should prompt for a password (for encrypted journals) after writing a new entry. If the user fails their password 3 times, though, we should send them back to the editor with their content intact instead of dying and losing the new entry.

This way, we can fix both issues without more regressions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working major Has potential for data loss 📌 This can't go stale
Projects
None yet
Development

No branches or pull requests

3 participants