rns.recipes

Obligatory running on Windows.
I'm attempting to clone an rngit repo using the method outlined in the manual of git clone rns://xxxxx/group/repo but the bundle file stored temporarily in %userprofile%\.reticulum\storage\resources\ isn't processed completely and otherwise completely disappears. Have tried with antivirus disabled as well, just in case something got tripped up there.

Here's the line from the log file (minor redaction/trucation):
[2026-08-18 22:12:11] [Error] Error while executing response received callback from <RNS.Link.RequestReceipt object at 0x0000018422837610>. The contained exception was: [WinError 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\xxxxx/.reticulum/storage/resources/xxxxx'

Anyone else having issues? Windows-only issue?

Well i can only say that i haven't encountered this on linux.
Somehow i think windows or normal git tries to access it while rngit didn't finish its job with it, some kind of concurrency issue going on.

Had a bit of time to dig into this, turns out it was a missing closure for the bundle file prior to it being moved by rngit.

Where the "file is being used" error actually originates: _response_ready in rngit calls shutil.move().

Following all the back to the origination of the file object: assemble in Resource opens the bundle file, calls the callback response_resource_concluded in Link -> handle_response -> response_received-> (callback) _response_ready in client.py of rngit.

In that chain, the open file object is passed all the way to rngit, verified by adding a check on self.request_response.closed and logging the result.

Adding self.request_response.close() after line 292 in rngit/client.py got it moving along and I successfully cloned a repo. Now there's an error that gets pushed to terminal at finish when the "end of batch" segment of run gets to git_stdout.flush() as it generates an OSError for "invalid argument" rather than the caught BrokenPipeError exception.

Moral of the story: Windows is goofy.

I see commit 05e6717 implemented a fix, thanks Mark!