Windows file locking issue when `--output-dir` is used on single file render (non project context)

[cderv]

It is an interesting use case because it reliably recreate on windows the OSERROR 32

ERROR: Le processus ne peut pas accéder au fichier car ce fichier est utilisé par un autre processus. (os error 32): remove 'C:\Users\chris\AppData\Local\Temp\quarto\test_quarto\.quarto'

• os error 32? #10775
• windows - wait to file to unlock for removal #10629

I'll have a look in this.

Originally posted by @cderv in #13623

See the reprex in the above issue that does recreate the issue each time.

[cderv]

This is again another Deno.kv() problem because on windows the database is locked.

When single file render happens we do create special context that uses global temp context, but when --output-dir flag is set we do even more specific by mimicking a project which mean .quarto scratch dir is created

quarto-cli/src/command/render/render-shared.ts

Lines 51 to 58 in 537a0f9

	// if there is no project parent and an output-dir was passed, then force a project
	if (!context && options.flags?.outputDir) {
	// recompute context
	context = await projectContextForDirectory(path, nbContext, options);
	// force clean as --output-dir implies fully overwrite the target
	options.forceClean = options.flags.clean !== false;
	}

we don't want that so we set forceClean which triggers a cleaning of .quarto folder

quarto-cli/src/command/render/project.ts

Lines 889 to 900 in 537a0f9

	// in addition to the cleanup above, if forceClean is set, we need to clean up the project scratch dir
	// entirely. See options.forceClean in render-shared.ts
	// .quarto is really a fiction created because of `--output-dir` being set on non-project
	// renders
	//
	// cf https://github.com/quarto-dev/quarto-cli/issues/9745#issuecomment-2125951545
	if (projectRenderConfig.options.forceClean) {
	const scratchDir = join(projDir, kQuartoScratch);
	if (existsSync(scratchDir)) {
	safeRemoveSync(scratchDir, { recursive: true });
	}
	}

but when we try to do this cleaning, I think deno.kv() locking has not yet been closed because we do that in context.cleanup()

quarto-cli/src/project/types/single-file/single-file.ts

Lines 84 to 87 in 537a0f9

	cleanup: once(() => {
	cleanupFileInformationCache(result);
	result.diskCache.close();
	}),

which happens later.

So this is another case for

• windows - wait to file to unlock for removal #10629

but that should probably be solved correctly by doing the cleaning in the right order