Saving a connection fails on Windows: *.temp connection folder cannot be renamed (open handle on credentials.sso)

[davidcarosoltel-source]

Saving a connection fails on Windows: *.temp connection folder cannot be renamed (open handle on credentials.sso)

Summary

On Windows, creating/saving a database connection intermittently (for us, consistently) fails with a "could not be created" error. The extension writes the connection into a <id>.temp directory under %APPDATA%\DBTools\connections\ and then tries to rename it to <id> (dropping .temp). That final rename fails because the extension/its backend still holds an open file handle on credentials.sso inside that directory, and Windows does not allow renaming a directory that contains a file with an open handle. A moment later the same rename succeeds, which proves it is a timing/handle-release issue inside the extension, not an environment problem.

Environment

• Extension: Oracle SQL Developer for VS Code 26.1.2 (May 2026)
• OS: Windows 11 Pro 10.0.26200
• Connection type: Basic (host / port / service name), with Save Password enabled
• Windows Defender real-time protection: on
• Controlled Folder Access: off

Exact error message

Error: The resource identified by : <CONN_ID> could not be created due to an unexpected error.
An unexpected error occurred during the create operation:
C:\Users\<USER>\AppData\Roaming\DBTools\connections\<CONN_ID>.temp ->
C:\Users\<USER>\AppData\Roaming\DBTools\connections\<CONN_ID>.
Ensure the resource is correctly formed.

Steps to reproduce

1. On Windows, open the Oracle panel → Create Connection.
2. Fill in a Basic connection (name, user, password, host, port, service name) and check Save Password.
3. Click Save (or Test then Save).
4. The error above appears and the connection is not added to the tree.

Observed state on disk

After a failed save, the connections folder contains a leftover directory with the .temp suffix, fully populated:

%APPDATA%\DBTools\connections\
  <CONN_ID>.temp\
    credentials.sso        (~409 bytes)
    dbtools.properties
    ojdbc.properties

The intended target directory (<CONN_ID> without .temp) does not exist — so this is not a "target already exists" collision. Retrying the save produces additional *.temp directories (they accumulate, one per failed attempt).

Evidence this is NOT an environment / antivirus / permissions issue

• Manual rename works: renaming <CONN_ID>.temp → <CONN_ID> by hand (PowerShell/Explorer) succeeds immediately, and the connection then shows up correctly after a window reload.
• Rapid rename stress test passes 25/25: a script that, in the exact same connections folder, repeatedly does mkdir <x>.temp → write a credentials.sso + dbtools.properties inside → rename <x>.temp <x>, 25 times in a tight loop, succeeded every time with zero failures. So the OS/AV has no problem renaming these directories (even with a freshly written credentials.sso inside).
• Controlled Folder Access is disabled, so it is not blocking the write/rename.

The only difference between the passing stress test and the failing extension flow is that the extension still has credentials.sso open when it issues the rename.

Likely root cause

The connection save sequence appears to be:

1. Create <id>.temp\
2. Write credentials.sso (secure wallet) + dbtools.properties + ojdbc.properties
3. Rename <id>.temp → <id>

Step 3 is executed before the handle opened in step 2 (the .sso wallet, likely written by the bundled dbtools/SQLcl Java backend) is closed/flushed. On Windows, rename/MoveFile on a directory fails with access-denied while any contained file has an open handle. On POSIX this would succeed, which may be why it is Windows-specific.

Suggested fix

• Ensure the credentials.sso file handle (and any other handle into the .temp directory) is fully closed/flushed before issuing the directory rename.
• Optionally add a short retry-with-backoff around the rename on Windows, and clean up orphaned *.temp directories on next save/startup.

Current workaround

A small script that finalizes orphaned connection folders by renaming *.temp → final name (retrying a few times until the handle is released). This recovers the connection without re-entering its data.

Impact

Connections cannot be saved through the UI on affected Windows setups; users must apply a manual workaround after every save, and *.temp directories accumulate under %APPDATA%\DBTools\connections\.