Could not persist output to disk on windows

[blindFS]

Describe the bug

As reported by a windows user in
blindFS/topiary-nushell#1 (comment)

❯ topiary format toolkit.nu
[2024-12-20T15:29:41Z ERROR topiary] Could not persist output to disk
[2024-12-20T15:29:41Z ERROR topiary] Cause: Access is denied. (os error 5)

To Reproduce

1. manually compile https://github.com/nushell/tree-sitter-nu with tree-sitter build on windows
2. specify the dll file path in languages.ncl
3. run topiary format *.nu

Expected behavior
write formatted code back to the input file.

Environment

• OS name + version: windows + latest commit
• parser also at the latest commit

Additional context
Add any other context about the problem here.

[yannham]

Ah, it's nice that we get some Windows users (and even nicer that it actually works, at least up to some point 😅 ). I'm going to tag @fdncred here directly to avoid polluting the topiary-nushell issue. I haven't used Windows in ages, and I suspect this is the case for most people working on Topiary. But naive question first: is it possible that, as the error says, it's just a permission problem? Like the directory or the file is read-only?

[Xophmeister]

Dynamic loading of grammars is untested under Windows. Either way, it's not clear from this error where it's going wrong. Could you increase the logging verbosity (-vvv) to see if this makes it clearer to see where the problem occurs?

[fdncred]

Thanks for the suggestions!

But naive question first: is it possible that, as the error says, it's just a permission problem?

It's not. I/my terminal has full write permissions to this folder.

Attached is the output of topiary -vvv format toolkit.nu o+e> out.txt.
out.txt
My guess is that the file, toolkit.nu, is being opened with an exclusive lock on windows and since that happens it can't write to it with that lock. But that's just a guess.

[Xophmeister]

I think your diagnosis looks quite likely. The logs show that the grammar loading seems to be working fine; Topiary does it's formatting, but then fails when it tries to write the output.

When an input file is specified, we store its path and, when we want to read from it, it's opened read only (std::fs::File::open). The output is actually written to a temporary file (that exists alongside the input) and then "persisted" to the original file when everything's done. When that final operation happens, the input file is still open.

The documentation for the persistence operation suggests that the temporary file is moved to the final output location (i.e., the input file). The logs show it's this that's failing. (I believe that happens in the library code here, FWIW.)

Unfortunately I don't have any way to test this, but if Windows is taking an exclusive lock as you suggest, then this branch should (I think) offer a fix. Would you be willing to be a guinea pig for this, @fdncred 🙏