Jrnl: Tempfiles on Windows

Created on 28 Mar 2016  路  13Comments  路  Source: jrnl-org/jrnl

Via Email:

I don't know if this is the right way to go about this, but I'm having a little trouble getting jrnl configured on my Windows 8 machine. I set vim as the editor in the configuration file, but when I run jrnl, it opens an instance of vim in read only mode. Looking at the traceback, it tries to run os.remove(tmpfile) but prompts a windows error saying "The process cannot access the file because it is being used by another process: c:\users\username\appdata\local\temp\jrnldokd2b.txt" I'm still a noob at trying to solve issues like this on my own, but it looks like mkstemp returns an open file which then causes problems when subprocess.call and os.remove try and mess with file. Is this right or am I barking up the wrong tree? And how would you solve the issue? Should I try explicitly closing the file after creating it and getting the path?

bug windows

Most helpful comment

Added this to util.py line 130:
os.close(_)

tempfile.mkstemp was holding an exclusive write handle, causing the file in use issue.

All 13 comments

@MinchinWeb You're on a windows box, right? Any idea what might cause this?

Indeed I am.

I ran into a similar (the same) issue when I was trying to set up Sublime Text as my editor. What is happening is that jrnl console script [1] is creating a python process [2], which in turn is creating the editor process [3], whether that's VIM, Notepad++, or Sublime Text 3.

The python process [2] maintains a handle on the temp file after it calls the editor. Some editors (like Notepad++) seem to ignore it, and will allow you to save your edits to the temp file. Other editors (like VIM and Sublime Text) seem to notice the other file handle and refuse to save changes to the file due to it being open by another process.

Possible solutions:

  1. Use Notepad++ as your editor
  2. have jrnl drop the file handle (but not delete the file) before calling the editor, and reopen the file handle after the editor has closed.

PR#416 implements option 2 by closing the filehandle before opening the editor. VIM and Sublime Text 3 now work on my end as editors.

Bump.

E:\Home>jrnl
Traceback (most recent call last):
  File "C:\Software\Python\Python35-32\Scripts\jrnl-script.py", line 9, in <module>
    load_entry_point('jrnl==1.9.8', 'console_scripts', 'jrnl')()
  File "c:\software\python\python35-32\lib\site-packages\jrnl\cli.py", line 207, in run
    raw = util.get_text_from_editor(config)
  File "c:\software\python\python35-32\lib\site-packages\jrnl\util.py", line 136, in get_text_from_editor
    os.remove(tmpfile)
PermissionError: [WinError 32] Le processus ne peut pas acc茅der au fichier car ce fichier est utilis茅 par un autre processus: 'C:\\Users\\Adrien\\AppData\\Local\\Temp\\jrnlflaz6rwj.txt'

Current jrnl config:

{
"journals": {
"default": "P:\Users\holly/journal.txt"
},
"timeformat": "%Y-%m-%d %H:%M",
"linewrap": 79,
"highlight": true,
"editor": "C:\Program Files (x86)\Notepad++\notepad++.exe -multiInst -nosession",
"default_hour": 9,
"encrypt": false,
"tagsymbols": "@",
"default_minute": 0
}

Open entry fir editing in Notepad++

P:>jrnl -until yesterday --edit

Edit the file in Notepad++ and save it, exit Notepad++.

P:>jrnl -until yesterday --edit
Traceback (most recent call last):
File "C:\Program Files (x86)\Python35-32\Scriptsjrnl-script.py", line 11, in

load_entry_point('jrnl==1.9.8', 'console_scripts', 'jrnl')()
File "c:\program files (x86)\python35-32\lib\site-packagesjrnl\cli.py", line
277, in run
edited = util.get_text_from_editor(config, journal.editable_str())
File "c:\program files (x86)\python35-32\lib\site-packagesjrnl\util.py", line
136, in get_text_from_editor
os.remove(tmpfile)
PermissionError: [WinError 32] The process cannot access the file because it is
being used by another process: 'P:\Users\holly\AppData\Local\Temp\jrnlr7p
a7k07.txt

Although Notepad++ does not complain the entry edits are not saved when I retrieve them again they have not changed.

Added this to util.py line 130:
os.close(_)

tempfile.mkstemp was holding an exclusive write handle, causing the file in use issue.

I had the same issue and @hollystyles' fix worked for me.

I had the same issue and @hollystyles' fix worked for me.

jrnl 1.9.8 (installed with pip)
Windows 10
Notepad++ 7.5.4

@hollystyles' fix worked for me as well. Why isn't this fix already added to the application?

Opened a pull request #564 with the fix.

@maebert I think this was fixed by #564

@mzfr Yup, you're right. As we get caught up on the backlog we'll sort out these inconsistencies. Thanks for pointing it out!

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings