-
-
Notifications
You must be signed in to change notification settings - Fork 981
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
pandoc: openFile: does not exist (No such file or directory) #1268
Comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Just FYI I'm also seeing this error (trying to use rmarkdown with flexdashboard). Using the dev version unblocked things but I'm still seeing the error. |
@ADraginda Are you also on Shiny Server? Is it reproducible locally? |
I have the same issue, but only when I run rmarkdown::render(...) in parallel on multiple cores. When I do To reproduce, install the following R package and
reproducermarkdownerror_0.1.0.tar.gz Output (operation produces only 92 files although 100 expected):
Script taken from here: Version information:
|
I can reproduce this error locally. Using Create directory structure and file dir <- tempdir()
sub_dir <- tempfile(tmpdir = dir)
f <- tempfile(tmpdir = sub_dir)
dir.create(sub_dir)
writeLines("This is a test", f)
cwd <- getwd()
library(rmarkdown) This works setwd(sub_dir)
fname <- basename(f)
readLines(fname)
#> [1] "This is a test"
pandoc_convert(fname, to = "html") This doesn't: setwd(dir)
fname <- file.path(basename(sub_dir), basename(f))
readLines(fname)
#> [1] "This is a test"
pandoc_convert(fname, to = "html")
#> Error: pandoc document conversion failed with error 1 setwd(cwd)
sessionInfo()
#> R version 3.5.1 (2018-07-02)
#> Platform: x86_64-apple-darwin15.6.0 (64-bit)
#> Running under: macOS Sierra 10.12.6
#>
#> Matrix products: default
#> BLAS: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib
#> LAPACK: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib
#>
#> locale:
#> [1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
#>
#> attached base packages:
#> [1] stats graphics grDevices utils datasets methods base
#>
#> other attached packages:
#> [1] rmarkdown_1.10.12
#>
#> loaded via a namespace (and not attached):
#> [1] compiler_3.5.1 magrittr_1.5 htmltools_0.3.6 tools_3.5.1
#> [5] yaml_2.2.0 Rcpp_0.12.18 stringi_1.2.4 knitr_1.20
#> [9] htmldeps_0.1.1 digest_0.6.16 stringr_1.3.1 evaluate_0.11 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I solved it by changing my RStudio global options and setting the R version to be the local C:\ drive and not R on the network drive. |
If the Rmd file is stored on a network drive, the knitting fails. However, if the Rmd file is stored on the local C:\ drive, the knitting works fine. YAML
Network drive
Local C:\ drive
Session Info
RStudio Version
|
Just save the Rmd file to the C:\ drive rather than desktop (Network Drive). This solved my problem while I have struggled a month... |
@yihui - although there is a very simple work around (store Rmd file on C:\ rather than network drive), some of us are not allowed to save files on our C:\ (per company policy and/or using RStudio Server Pro with mounted network folders). Is there a plan to fix rmarkdown or knitr such that Rmd files that are stored on a network drive can still knit? |
I think this is the same issue as in #701 where there is already a long discussion. An issue was even opened to pandoc (jgm/pandoc#1326) as it is in fact a more general issue with pandoc than just Rmarkdown. it was conclude that it could come from the drive directly, and that it is not specific to R or Rmarkdown tools (#701 (comment)) Currently solution is to copy locally somewhere (not necessary in C:) before doing the conversion. see for example #701 (comment) or other comments. To share experience, on a RStudio Server Pro (linux) with NFS mounted drive, we have no issue with that. At the time, I manage to change some directory argument from Rmarkdown (#701 (comment)) to get the intermediaries files on local drive. (my home directory was on local drive).
I think any local folder where you have access right will work. Not just C:/ . You could have a home directory or even a temp directory to move your file before knitting. (R has one in Hope it helps. |
FYI Seeing the same issue using Rstudio in a windows VM. Setting the default working directory in Rstudio to a drive letter (e.g., Z:) in "Tools > Global options > General" rather than the default "~" resolved the issue. |
I'm trying to do multiple reports (https://www.reed.edu/data-at-reed/software/R/markdown_multiple_reports.html) and with mtcars works fine, but if I do the same with my own dataframe loaded from a *.csv doesn't work. I don't know how to fix it nor I understand why and how is happening, I'm on a local computer. sessionInfo() Matrix products: default locale: attached base packages: other attached packages: loaded via a namespace (and not attached): |
I encountered the same error knitting to HTML from an .Rmd on a network drive. My working directory was already local. However, clearing the knitr cache resolved the issue. |
The solution by @vthivierge worked for me. |
100% fix when you open a project on a mapped drive do not open it through the shortcut to the mapped drive #this works and happens automatically when you open the Rstudio project through that path this is what happens when you open it wrong the knit command cannot operate on this path |
Watch out used open file in recents and in "Quick Access" in windows 10 when opening Rstudio projects always brows to the actual mapped drive letter or set up a short cut that explicitly does that. |
Thank you!! This solved it for me. |
I'm having the same issue on a Mac. Would anyone be able to assist on how to map the files properly to overcome this glitch since there is no C:/ drive? It seems like the solution is possible but I can't get it to work on my system! Thank you! |
You can use "~/" as a shortcut for home directory, or you can refer to the
absolute path, which will be something like /Users/Vicki , /Users/[your
username on the machine]
Joe Wasserman
[email protected]
https://www.joewasserman.com
…On Thu, Jan 2, 2020 at 3:56 PM vickibendus ***@***.***> wrote:
I'm having the same issue on a Mac. Would anyone be able to assist on how
to map the files properly to overcome this glitch since there is no C:/
drive? It seems like the solution is possible but I can't get it to work on
my system! Thank you!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1268?email_source=notifications&email_token=AH4TPUVHQKESIT2NTR3MX43Q3ZIHBA5CNFSM4ESHCZKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH7MM3I#issuecomment-570345069>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH4TPURW7GAVR35JJ7ZDU53Q3ZIHBANCNFSM4ESHCZKA>
.
|
Shoot that doesn't seem to be a solution for me then. My current working directory is "/Users/vickibendus/Desktop/R Materials/Soccer Reports", which appears to be the correct type of path. I'll have to keep searching for a way around this problem. |
@MTF-UMass thanks a lot ! That is really good to know - that means unfortunately Pandoc still have the issue. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@cderv absolutely, sorry about that
|
Thanks a lot for your help ! |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Just chiming in with my experiences with RStudio 1.4+ and pandoc 2.14.1. 2.14.1 has fixed the ".Rmd file located in the user roaming profile (i.e. UNC path) issue", so if RStudio updates to this version of pandoc then that is solved as far as I can tell. However, there is a related problem: If the .libPaths() is on a roaming profile (UNC) location, and rmarkdown is installed into that location then you get basically the same error, presumably due to pandoc not loading the template files etc correctly. This is supposed to be fixed in pandoc 2.14.1: But it seems that it isn't completely fixed. Am not sure exactly which bit is failing, output is like this:
In addition, two warnings are generated, suggesting it might be fixable within rmarkdown maybe?
Everything works fine, and the warnings are not generated if the UNC path is mapped to a drive and then R_LIBS_USER is set accordingly. |
It seems like windows people have some kind of work around. But non-windows using drive over cifs are not so lucky. I have seen a similar issue on jupyter because by default they tried to enforce atomic write which didn't work so well on remote file system. It kind of works the first time but after that you have some kind of ghost files preventing things from working. I got the following message from the r markdown window
when I look at my file system I have
But I feel one the reason things don't work, is that temporary files are created in place instead of a proper temporary location, |
@jmarshallnz @kiwifb Thanks a lot that is very helpful ! With your comment, I believe we have something to reproduce. It require to setup an environment with UNC path, so it won't be straightforward for me. Also, we still don't know for sure if this is Pandoc or rmarkdown. It is probably both. @jabranham the commit you linked to (jgm/pandoc@26ed7fb) is in a release version since Pandoc 2.11. When you say
Do you have another fix in Pandoc in mind ? FWIW, next RStudio IDE version should be shipped with 2.14.1 @kiwifb The error you get is clearly not from Pandoc and it different. If you can reproduce, can you share also the We'll try to make quicker progress with your information, thanks for sharing ! We definitely need to reproduce this in order to better dig into the issue with file managements and computation with network drive. Thanks again |
@cderv Yes, you're right about that commit being in 2.11. Strange. There definitely is a difference in behaviour between pandoc 2.11 and 2.14.1 with RStudio 1.4. With v2.11 I can reproduce (everytime) the fault where the .Rmd is stored in a UNC path it fails to build. With 2.14.1 this is gone, except for the case where rmarkdown is also installed on a UNC path. I can't really see anything obvious in pandoc other than that commit, so not sure what fixed (part of) the problem. |
Then it is possible that something in RStudio IDE helped fix this issue. There was also non-pandoc issue with RStudio IDE and UNC path I believe. With what you say, it could mean that next version of RStudio IDE with Pandoc 2.14.1 should be better. We would need to look then more at the issue with rmarkdown package on network drive. For this, I am thinking we may need to copy the resources included into the package locally so that Pandoc does not need to access them through network drive (if that is the issue). Currently, some resource are passed to pandoc using absolute path to rmarkdown installation folder. |
My setup is a rstudio server running on ubuntu 20.04 with some remote folders mounted via cifs. The previous error I think had some extra layers of indirections because the filename had space in it, which lead to extra normalization.
But the second time (or sometimes more time, it is a bit finicky) I now get
I am doing everything from the rstudio interface at the moment, how do I run things to get to the backtrace you want. I can run R directly from the command line if needed. |
Figured it out by running
|
That is a bit disturbing to me that this is sometimes working, and sometimes not. Thanks for sharing the setup. I'll see if I can get my hand of such configuration. |
I think there is a lot to be done around some remote file system. What personally gets my attention as a programer in other language and context is that the intermediary file (in |
I understand you point, and I think what you describe applies to more standard temporary content. However, for the specific usage here, we need to consider the way Pandoc is working. For example, it is highly possible that We are a bit off topic here. You can open a new issue if you want to discuss some ways to improve that (Knitr + Pandoc + LaTeX interaction needs to be considered here). Thanks ! |
Ha, it just proves that I am completely ignorant of the context and that I don't know what I am talking about. I have been spending a few hours looking at the code earlier today and I couldn't really untangle the various abstractions. R is not the language I am the most familiar with. I have come to that conversation because I am supporting a lecturer for whom I have organised the particular setup. The cifs mount is to access our university shared file system for convenience. As it turns out it is not currently convenient to run a number of things including knitting directly on it :) |
Thanks for chiming in then ! We really appreciate having also external contributors with different background to share views and thoughts on the ecosystem because it brings new perspective. If you still want to look deeper with your setup (and I think that would us), you could try without R and rmarkdown, using directly Pandoc to convert a document with different scenarios. For example :
If this does not work well at this level, then it is why we have a hard time looking at it from our level 🤔 |
Just in case: I was getting this error with a Solution: don't track/copy |
This solved my problem with R Markdown. Thank you so much |
I am trying to server Rmd using shiny server. However, it seems rmarkdown or pandoc is buggy.
It works well on Rstudio but fails deploy on rstudio connect too.
yaml config:
Rmarkdown version:
pandoc version
sessionInfo():
here is the shiny server log:
The text was updated successfully, but these errors were encountered: