Nextcloud Windows Client Fails to Restore Sync Root in RAM Drive After Reboot

Describe the bug
When using a RAM drive as the sync root folder for the Nextcloud Windows desktop client, the client fails to restore the sync connection after a reboot or when the RAM drive is recreated. The sync connection is lost, and the client displays some files couldn't be synced.
The Linux client does not have this problem and seamlessly resumes syncing when the RAM drive is recreated.

To Reproduce
Steps to reproduce the behavior:

Set up a RAM drive (ImDisk) in Windows.

Configure the Nextcloud Windows client to use a folder on the RAM drive as the sync root.

Allow syncing to complete.

Reboot the PC.

Expected behavior
The Nextcloud client should detect that the sync root path has returned and resume syncing files automatically, matching the behavior of the Linux client.

Actual behavior
The Nextcloud Windows client does not resume syncing.

No files are synced until the sync folder is manually reconfigured.

On Linux, the client resumes syncing immediately after the RAM drive reappears.

Client Configuration
Operating system: Windows 11

Nextcloud Desktop Client version: (3.16.4)

RAM drive software: (ImDisk)

Is the RAM drive assigned the same drive letter each time? Yes

Does the RAM drive support persistent volume serial numbers? Don’t know

Nextcloud server version: (31.0.4.1)

Additional context
The issue appears to be related to the Nextcloud client’s method of identifying the sync root on Windows (possibly using a unique volume serial or internal ID that changes on each RAM drive recreation).

On Linux, the client does not have this issue and resumes syncing as soon as the ramdrive is present.

Summary
This issue reduces usability for users who wish to use high-speed, ephemeral storage for syncing, testing, or privacy reasons. The behavior between platforms is inconsistent.