Cannot clear docs/_build directory due to locked database files

[marcel-22]

Expected behavior

We have a script to clear (remove) the build directory. This does not work anymore due to locked Esbonio database files.

Actual behavior

When I try to delete the docs/_build directory I get the following errors:

$ rm -fr docs/_build
rm: cannot remove 'docs/_build/html/esbonio.db': Device or resource busy
rm: cannot remove 'docs/_build/html/esbonio.db-shm': Device or resource busy
rm: cannot remove 'docs/_build/html/esbonio.db-wal': Device or resource busy

If I try to delete it in Windows Explorer, it says The action can't be completed because the file is open in Python. When I close VS Code and then delete the folder it's gone. How can we make sure the docs/_build directory can be removed successfully? This should work independently from the Preview function. For example, we have scripts to clear the entire code and documentation builds and rebuild everything from scratch, if necessary.

Log output

No response

(Optional) Settings from conf.py

No response

[marcel-22]

The easiest and cleanest solution would be to store the database files outside of docs/_build so that they don't interfere.

My thoughts would be to have some Esbonio storage folder - in %APPDATA% or %LOCALAPPDATA%, I am not sure - and create a directory for each project there with the preview database files stored in them.

I snooped around a bit and I found something like %APPDATA%\Code\User\workspaceStorage. You could create a hash for each folder location like is seen here and store documents inside them, but then I found some older project/hash folder inside workspaceStorage that already had a subfolder called swyddfa.esbonio. So wouldn't it be possible to use this? It seems like you have done it before.

[marcel-22]

An alternative option could be to store the Esbonio database files in the .vscode folder. But this should be user configurable I guess. Or we could build the Esbonio documentation in another folder instead. Is there a way to reference the exact folder location in workspaceStorage for the open folder/workspace that you know of?

The comments in this topic might be of interest to you: microsoft/vscode#22557

[alcarney]

I found some older project/hash folder inside workspaceStorage that already had a subfolder called swyddfa.esbonio. So wouldn't it be possible to use this? It seems like you have done it before.

Yes... but it's VSCode specific and the server would have to be told about it via a config option set by the extension (not necessarily a bad thing and how it works in the stable release).

Or we could build the Esbonio documentation in another folder instead

If the esbonio.sphinx.buildCommand option accepted something like ["sphinx-build", "-M", "html", "docs", "${defaultBuildDir}", "-t", "preview", "-W", "--keep-going"], so that the server could place the files "somewhere else" but still allow you to set the other cli flags would that be enough?

Or shall I also add a separate esbonio.sphinx.databaseDir option as well?

Is there a way to reference the exact folder location in workspaceStorage for the open folder/workspace that you know of?

The only way to reference it I know of is via the VSCode API in the extension itself...

[marcel-22]

If the esbonio.sphinx.buildCommand option accepted something like ["sphinx-build", "-M", "html", "docs", "${defaultBuildDir}", "-t", "preview", "-W", "--keep-going"], so that the server could place the files "somewhere else" but still allow you to set the other cli flags would that be enough?

Hm, yes, that would fix the whole issue! And this behavior would be similar to the current stable release version I think.

Or shall I also add a separate esbonio.sphinx.databaseDir option as well?

With the above solution it won't be needed in our case, but for people who want to have the exact same build location for the preview docs and normal docs that would be an option to solve the issue with the locked database files.

The only way to reference it I know of is via the VSCode API in the extension itself...

Thanks. Yes, I thought that as well. But with your suggested solution using ${defaultBuildDir} which resolves to some other folder, and not part of our workspace, this won't be needed.

[marcel-22]

Is this included in the new pre-release?

[alcarney]

The ${defaultBuildDir} variable, yes

[marcel-22]

Thanks! I have it running now, in a multi-root workspace setup 😊 Nice work 👍👍👍