cannot create lock file -- (well known?) problems with knitr using 'dev=tikz'

[janblue]

Hello,

I'm having a problem using knitr with tikzDevice (version 0.6.3) , when choosing tikz as output-format (with pdf-format everythink is fine): '

---

Error in createLockFile(lockname) : cannot create lock file

---

Seems to be the (well-known?) filehash-problem with tikzDevice?!

Suggestion was to delete the _lock-file (http://lists.r-forge.r-project.org/pipermail/tikzdevice-bugs/2011-May/000202.html), but: I can't find any _lock-file on my system. Where is it?

Or any suggestions to solve the problem? (Referring to the version report,I thought, version 0.6.3 fixed maybe the bug: "Calls to the Filehash package have been protected from user interruptions. This should prevent rogue lockfiles and corrupted metrics dictionaries.", but it seems not to work...)

I would really like to get a tikz-output. Thanks so much for any hint, how to solve the problem...

Jan!

[Sharpie]

On Mon, Feb 4, 2013 at 9:42 AM, janblue notifications@github.com wrote:

Hello,

I'm having a problem using knitr with tikzDevice (version 0.6.3) , when choosing tikz as output-format (with pdf-format everythink is fine):

'

Error in createLockFile(lockname) : cannot create lock file

Seems to be the (well-known?) filehash-problem with tikzDevice?!

Suggestion was to delete the _lock-file ( http://lists.r-forge.r-project.org/pipermail/tikzdevice-bugs/2011-May/000202.html), but: I can't find any _lock-file on my system. Where is it?

Or any suggestions to solve the problem? (Referring to the version report,I thought, version 0.6.3 fixed maybe the bug: "Calls to the Filehash package have been protected from user interruptions. This should prevent rogue lockfiles and corrupted metrics dictionaries.", but it seems not to work...)

I would really like to get a tikz-output. Thanks so much for any hint, how to solve the problem...

Jan!

Hi Jan,

The issue with the lockfile that was fixed only arises when the user interrupts R while it is in the middle of creating a graph. But it doesn't sound like you were succeeding at producing graphs, then hit CTRL-C or interrupted R and suddenly started failing to produce graphs.

Another cause of this could be that you don't have permissions to write to the location returned by tempdir(). If this is the cause, you can work around it by specifying a location for the metrics dictionary as specified in the "Options That Affect Package Behavior" section of ?tikzDevice.

Hope this helps!

-Charlie

[janblue]

Thanks a lot for the fast answer.

You are right, I'm not hitting CTRL-C when compiling (perhaps I did once in the past -- Is it possible, that there are left any artefacts?)

Changing the metrics dictionary path to a 'save' location doesn't work either. (I think in the past once I got a minimal example work, when starting a new R-Project in R-Studio, but that doesn' work either any more.)

If artefacts could be the problem: Is there a (brute force) way to reset the system (reinstall R, deleting a special path or something like that or are there local settings which will cause the same problem againg), to make it work? I have already spent several hours in finding a solution, so for me reinstalling R is no question of time any more... (if there is chance of not reproducing the same error afterwards)

Thanks a lot for a short hint.

Jan!

[Sharpie]

If you tried setting the dictionary path, then corruption is an unlikely problem as an entirely new dictionary file is built from scratch at the new location. Seems like something else is going on here.

What operating system and version of R are you using?

[janblue]

Hello Sharpie, I once again checked the possibilities for errors the whole day. Now it's working.

YOU HAD THE RIGHT IDEA. It was a problem of a path name. I had a german "ö" in one of the path name of the project directory (and -- ironically -- again in the path name, when chaning the path of the metrics dictionary)

Changing it to "oe" solved the whole problem! Such a small letter kept me searching for hours and hours again ... Thank you so much for your help and your crucial hint :):):) And thanks for your work on TikzDevice, its producing really nice output for latex...

Jan!

[Sharpie]

Glad you got it working and thanks for the follow up. I will improve the error message that gets produced in this situation when I get time to work on tikzDevice development again.

Thanks for the report!

[jonathan-g]

I have discovered that, at least under Windows 7 (64 bit), there appears to be a race condition in the OS, where the lockfile is sometimes deleted, but a subsequent call to lock_file fails because the OS reports the lockfile is still present. This happens intermittently, but frequently, on several systems I use.

Waiting a few hundred milliseconds and trying again seems to solve this.

See the issue and pull request at the filehash git: https://github.com/rdpeng/filehash/pull/6

[kendonB]

I have been getting this issue when using tikz and ggplot2 in a knitr chunk with Windows 8.1. While this hasn't yet been merged into the filehash package, how am I able to get this patch to work on my system? Thanks so much!

EDIT: I worked out how to do this. Any readers also confused can simply do the following to update the filehash package:

library(devtools)
install_github(repo = "jonathan-g/filehash")

[krlmlr]

@kendonB: Exactly. You could also say devtools::install_github("rdpeng/filehash#6"). Does the fix work for you? This feedback might be valuable for @rdpeng, the maintainer of filehash.

[kendonB]

The fix works perfectly. The problem was intermittent, until I had a few plots getting generated all at once and then the problem was consistent. No errors since updating with the patch. @rdpeng

[rdpeng]

I've incorporated @jonathan-g fix into the 'next' branch of filehash. If that seems to work for Windows users I'll merge it into 'master' soon.

[krlmlr]

@rdpeng: Thanks. Just as a reminder: This branch can be installed with devtools::install_github("rdpeng/filehash@next").