mkdir tries to create current directory when TeX file in parent and .latexmkrc specifies "build"

[ordinary-slim]

Description

With this project structure

.
├── metadata.tex
└── subfolder
    ├── .latexmkrc
    └── main.tex

and .latexmkrc specifying

$out_dir = 'build';
$aux_dir = 'build';

VimtexCompile errors in its first run, trying to create the current folder when build is still absent:

VimTeX: Creating directorie(s):
        * [...]/subfolder/build/..
Error detected while processing function vimtex#compiler#compile[7]..vimtex#compiler#start[18]..38[3]..56[1]..32:
line   29:
E739: Cannot create directory [...]/subfolder/build/..: file already exists

This boils down to call mkdir("./build/..", "p"), and build has not been created yet. This errors despite the "p" flag. After the first run, the project structure is:

.
├── metadata.tex
└── subfolder
    ├── build
    ├── .latexmkrc
    └── main.tex

and consequent runs don't error.

Steps to reproduce

1. https://github.com/ordinary-slim/vimtex-mkdir-bug
2. I believe this will error regardless of the config. Open main.tex in subfolder and run `VimtexCompile

Expected behavior

Vimtex should not try to mkdir the current folder, and not like this: ./build/.., where build is still absent.

Actual behavior

Vimtex runs mkdir("./build/..", "p"), where build is still absent, and errors in its first run.

Do you use a latexmkrc file?

Yes

VimtexInfo

System info:
  OS: Linux 6.17.5-arch1-1 (I use arch btw)
  LaTeX version: pdfTeX 3.141592653-2.6-1.40.28 (TeX Live 2025)
  Vim version: NVIM v0.11.4
  Has clientserver: true
  Servername: /run/user/1000/nvim.134803.0
  $PATH:
    - /bin
    - /home/mehdi/.local/bin
    - /home/mehdi/.local/share/nvim/mason/bin
    - /sbin
    - /usr/bin
    - /usr/bin/core_perl
    - /usr/bin/site_perl
    - /usr/bin/vendor_perl
    - /usr/local/bin
    - /usr/local/sbin
    - /usr/local/texlive/2025/bin/x86_64-linux
    - /usr/sbin

VimTeX project: main
  base: main.tex
  root: /home/mehdi/Documents/bug-vimtex/subfolder
  tex: /home/mehdi/Documents/bug-vimtex/subfolder/main.tex
  main parser: current file verified
  document class: article
  document class options: 
  source files:
    main.tex
    ../metadata.tex
  compiler: latexmk
    engine: -pdf
    options:
      -pdf
      -shell-escape
      -verbose
      -file-line-error
      -interaction=nonstopmode
      -synctex=1
      -f
    out_dir: build
    aux_dir: build
    callback: 1
    continuous: 1
    executable: latexmk
  viewer: Zathura
    xwin id: 0
  qf method: LaTeX logfile

[lervag]

Hi!

Steps to reproduce

1. https://github.com/ordinary-slim/vimtex-mkdir-bug

2. I believe this will error regardless of the config. Open main.tex in subfolder and run `VimtexCompile

I'm still interested in the config, though. I've never seen this error before, and I know people are using build directories without issues.

Now, for clarity: with "Open main.tex" - you mean a) open a terminal, b) cd to the subfolder directory, and then c) nvim main.tex, right?

I notice you propose a fix for this, but I want to actually understand the issue before I accept the fix.

[ordinary-slim]

Hi @lervag , great plugin!

Steps to reproduce

1. Example LaTeX project: https://github.com/ordinary-slim/vimtex-mkdir-bug
2. Minimal config (Lazy + vimtex):

-- Lazy (plugin manager) setup
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "https://github.com/folke/lazy.nvim.git",
    "--branch=stable", -- latest stable release
    lazypath,
  })
end
vim.opt.rtp:prepend(lazypath)

require("lazy").setup({
	spec = {
	{
	  "lervag/vimtex",
	  config = function()
	    vim.g.vimtex_compiler_method = "latexmk"
	    vim.g.vimtex_complete_enabled = false
	    vim.g.vimtex_quickfix_enabled = true
	    vim.g.vimtex_quickfix_mode = 0
	    vim.g.vimtex_syntax_conceal_disable = true

	    -- Use the following command for inverse search on Linux / macOS
	    --   nvim --headless -c "VimtexInverseSearch %l '%f'"
	    -- and the following on Windows (to reduce CMD popping)
	    --   cmd /c start /min "" nvim --headless -c "VimtexInverseSearch %l '%f'"

	    -- \ll to toggle interactive compilation (updates / launches PDF viewer on saved change)
	    -- \lk to interrupt compilation
	    -- \lc to clean files
	    -- \lo to inspect output
	    -- \li to see compile commands

	    
	    -- Live compilation
	    vim.g.vimtex_compiler_latexmk = {
	      build_dir = "",
	      options = {
		"-pdf",
		"-shell-escape",
		"-verbose",
		"-file-line-error",
		"-interaction=nonstopmode",
		"-synctex=1",
		"-f",
	      },
	    }

	    vim.g.vimtex_view_method = "zathura"
	  end,
	},
	}
})

I'm still interested in the config, though. I've never seen this error before, and I know people are using build directories without issues.

The issue is the combination of the build folder and the source file a folder above the project.

Now, for clarity: with "Open main.tex" - you mean a) open a terminal, b) cd to the subfolder directory, and then c) nvim main.tex, right?

Yes. Then run VimtexCompile. The first VimtexCompile crashes in the vimtex function s:compiler._create_build_dir. If you rerun VimtexCompile, it runs. If you run VimtexClean and VimtexCompile, it will crash again.

The function s:compiler._create_build_dir gets as an argument "build". Then it goes through get_sources and finds as sources main.tex and ../metadata.tex in this example. After this filter in the function:

    call filter(map(
          \ l:dirs, "fnamemodify(v:val, ':h')"),
          \ {_, x -> x !=# '.'})

, it has `l:dirs = [".."]. Then the second filter:

call filter(l:dirs, {_, x -> stridx(x, '../') != 0})

fails to drop ".." because it doesn't start with '../'. The function finally tries to call mkdir('build/..', 'p'), which crashes the first time, and works the second time because build is created by then. You can actually replicate the bug by running this vim command twice:

call mkdir("./folder_that_doesnt_exist_YET/..", "p")

The first time, it errors and creates folder_that_doesnt_exist_YET. The second time, it runs without issues.

[lervag]

Thanks for the kind words! And thanks for providing a minimal example!

So, first: I noticed a couple of things in the config. Here's an update version that should be equivalent - comments below:

vim.g.vimtex_complete_enabled = false
vim.g.vimtex_quickfix_mode = 0
vim.g.vimtex_syntax_conceal_disable = true
vim.g.vimtex_compiler_latexmk = {
  options = {
    "-shell-escape",
    "-verbose",
    "-file-line-error",
    "-interaction=nonstopmode",
    "-synctex=1",
  },
}
vim.g.vimtex_view_method = "zathura"

• I removed options that you didn't change from their defaults.
• For vimtex_compiler_latexmk:
  • I removed the build_dir - there is no such option!
  • I removed the -pdf option from options. Please read :help vimtex_compiler_latexmk, specifically the part about the options list.
  • I removed the -f option from options, as I think it does not really do anything necessary when we already have -interaction=nonstopmode.

Now, if I use your minimal config on the minimal example, I am not able to reproduce your problem at all. I therefore believe that there must be another component that is missing to reproduce this. Perhaps you also have a .latexmkrc file?

The issue is the combination of the build folder and the source file a folder above the project.

Yes, I can sort of understand your issue and your solution, but I have a slightly feeling that the problem is not actually with the code, but with your configuration/environment. So before I accept the PR I want to see how to reproduce this.

I also use Arch, btw., thus it should really be possible for me to reproduce this if it is an actual bug.

[lervag]

I'm sorry! I can reproduce the bug now. I noticed that there is a .latexmkrc file in your example; when I tested I didn't clone the repo, I just copied the tex files.

So, thanks for raising the issue with a good reproducible example! Let's continue the discussion in #3225.

[ordinary-slim]

Thank you for the comments on the configuration! See you in #3225