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

rmarkdown creates _files directory not cleared #1553

Closed
wxli0 opened this issue Mar 18, 2019 · 13 comments
Closed

rmarkdown creates _files directory not cleared #1553

wxli0 opened this issue Mar 18, 2019 · 13 comments
Labels
bug an unexpected problem or unintended behavior
Milestone

Comments

@wxli0
Copy link

@wxli0 wxli0 commented Mar 18, 2019

Hello,

I was playing with rmarkdown::render() function. After that, I found knit in rmarkdown always created an empty "_files" directory, which I do not want. Is there any commands that can help me get rid of this directory automatically? I have attached the all the render commands I have tried.

# output_dir <- "result"
# render()
# rmarkdown::render("6_1p_CSC05a_onset.Rmd", output_file = "result/6_1p_CSC05a_onset.pdf")
# rmarkdown::render('6_1p_CSC05a_onset.Rmd', 
#                   output_file='6_1p_CSC05a_onset.md')
# rmarkdown::render("6_1p_CSC05a_onset.Rmd")
# knit("doc.Rmd", "papers/doc.md")
# knit("6_1p_CSC05a_onset.Rmd", "result/6_1p_CSC05a_onset.md")
# opts_knit$set(output.dir="result")
# must place in the folder as iRaster.R due to source(...)
# rmarkdown::render("6_1p_CSC05a_onset.Rmd", output_format = "all",  clean = TRUE)

In my case, it always created 6_1p_CSC05a_onset_files folder in the same folder as 6_1p_CSC05a_onset.pdf. Any help would be appreciated!

@yihui yihui added the bug an unexpected problem or unintended behavior label Mar 19, 2019
@yihui yihui added this to the v1.13 milestone Mar 19, 2019
@wxli0
Copy link
Author

@wxli0 wxli0 commented Apr 8, 2019

Is there any update on this issue?

@olyerickson
Copy link

@olyerickson olyerickson commented Apr 9, 2019

It is normal for Markdown to create the empty "_files" directory, but it usually cleans up after itself. We sometimes see it left behind when a knit fails; for example, when our students attempt to knit an Rmd with Plotly figures to PDF.

Side note: These left-behind "_files" directories can be a real PITA in a collaborative, multi-user environment, since they usually are set with write access only for the user who generated them (RStudio Server doesn't set write for the group). This is not a "bug" per se, since RStudio Server is basically doing the right thing from a security standpoint...

@wxli0
Copy link
Author

@wxli0 wxli0 commented Apr 9, 2019

The "_files" directory is not cleaned up after knit and knit does not fail (i.e. the pdf has been generated successfully). Is there any command to force Rstudio to clean it up?

@p-gw
Copy link

@p-gw p-gw commented Apr 9, 2019

This is definitely new behaviour in v1.12.

I just looked at the recent changes in the render() function and there seem to be two changes related to #1472 and #1503:

if (output_format$clean_supporting && !dir_exists(cache_dir)) intermediates <- c(
  intermediates, if (identical(list.files(files_dir, '^figure-.+'), files_dir_fig)) {
    files_dir
  } else knitr::opts_chunk$get('fig.path')
)

This is a new evaluation of the intermediate directories compard to v1.11:

if (output_format$clean_supporting && !dir_exists(cache_dir))
  intermediates <- c(intermediates, files_dir)

The difference between the two versions is the inclusion of files_dir in intermediates which now depends on files_dir_fig. files_dir_fig gets assigned on line 402:

files_dir_fig <- list.files(files_dir, '^figure-.+')  # existing figure dir(s)

Because the _files directory get created in the knit() function call later (line 650), files_dir_fig just returns character(0) instead of the actual directory. Assigning files_dir_fig after the call to knit() returns the newly created directory and cleans up the _files directory correctly for this use case.

@yihui
Copy link
Member

@yihui yihui commented Apr 9, 2019

If I label an issue as "Bug", usually it means I have confirmed that it is a real bug, and will be fixed. If I also assign it to a milestone, it means it is important and should be fixed in the next version. Thanks for your patience!

@yihui
Copy link
Member

@yihui yihui commented Apr 12, 2019

Should be fixed now with @cderv's PR #1566. Thanks everyone!

@dchiu911
Copy link

@dchiu911 dchiu911 commented Apr 13, 2019

The fix isn't passed on to rmarkdown::render_site(), hence I am still getting the directory _bookdown_files/.../figure-html/... generated

@cderv
Copy link
Collaborator

@cderv cderv commented Apr 13, 2019

Can you open a new issue with a reproductible example on how it worked before and how it works now ?
I tested it with current issues and it works as I believe was expected
I need to see how it works with rmardown website. Or maybe bookdown here I guess ?
Also Not all rmardown format are cleanable format. A website has generally its ressources available as files and linked in the html.

@yihui
Copy link
Member

@yihui yihui commented Apr 13, 2019

@dchiu911 Judging from the directory name _bookdown_files, it seems you were using bookdown. If that is the case, _bookdown_files won't be automatically removed. This is by design, because bookdown pages are usually not self-contained. As @cderv said, we need more information from you to know whether it is a bug or not.

@wxli0
Copy link
Author

@wxli0 wxli0 commented Apr 14, 2019

Thanks very much.
Is updating "rmarkdown" package the only change I need to make to get rid of the _files directory?

@yihui
Copy link
Member

@yihui yihui commented Apr 14, 2019

Yes, you can install the development version via

remotes::install_github('rstudio/rmarkdown')

@dchiu911
Copy link

@dchiu911 dchiu911 commented Apr 16, 2019

@yihui if by design, not a bug, thanks.

@github-actions
Copy link

@github-actions github-actions bot commented Nov 3, 2020

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug an unexpected problem or unintended behavior
Projects
None yet
Development

No branches or pull requests

6 participants