On Windows, TorQ's built-in .os.ren implementation does not support moving a directory across volumes/drives.
This becomes a problem when WDB is configured with default writedown mode and the WDB location and HDB location are on different disks. In that mode, WDB needs to move the whole partition directory to HDB, but the current Windows rename/move behavior fails for that workflow.
Environment
- TorQ version: [v5.2.14]
- OS: Windows Server [Windows Server 2022 Standard, 21H2]
- kdb+ version: [4.1]
- WDB writedown mode:
default
- WDB path: on one Windows drive/volume
- HDB path: on a different Windows drive/volume
Problem
TorQ already supports WDB default writedown mode and has had recent Windows-specific fixes around WDB/IDB end-of-day handling. However, when WDB and HDB partitions are located on different disks, the built-in os.q move/rename utility does not handle the required directory move on Windows.
The result is that default writedown mode is not usable in this deployment layout, even though it is a valid and important configuration. This is especially relevant because default writedown mode can be materially faster than partbyenum under higher write load.
Steps To Reproduce
- Set up TorQ on Windows.
- Configure WDB to use
default writedown mode.
- Place the WDB root on one disk/volume, for example
D:.
- Place the HDB root on a different disk/volume, for example
E:.
- Run the normal WDB save/end-of-day flow that moves the written partition directory from WDB to HDB.
Actual Behaviour
The directory move fails on Windows when source and destination are on different drives/volumes, at EOD.
Expected Behaviour
TorQ should support this workflow on Windows by using a directory move/copy strategy that works across volumes, so WDB default writedown mode can complete successfully when WDB and HDB are on different disks.
Suggested Fix
Update the Windows implementation of .os.ren in code/common/os.q so that directory moves across volumes are supported.
For example, the Windows path could detect when the source is a directory and use a Windows-compatible cross-volume directory move approach rather than relying on the current UNIX-style rename/move behavior.
On Windows, TorQ's built-in
.os.renimplementation does not support moving a directory across volumes/drives.This becomes a problem when WDB is configured with
defaultwritedown mode and the WDB location and HDB location are on different disks. In that mode, WDB needs to move the whole partition directory to HDB, but the current Windows rename/move behavior fails for that workflow.Environment
defaultProblem
TorQ already supports WDB
defaultwritedown mode and has had recent Windows-specific fixes around WDB/IDB end-of-day handling. However, when WDB and HDB partitions are located on different disks, the built-inos.qmove/rename utility does not handle the required directory move on Windows.The result is that
defaultwritedown mode is not usable in this deployment layout, even though it is a valid and important configuration. This is especially relevant becausedefaultwritedown mode can be materially faster thanpartbyenumunder higher write load.Steps To Reproduce
defaultwritedown mode.D:.E:.Actual Behaviour
The directory move fails on Windows when source and destination are on different drives/volumes, at EOD.
Expected Behaviour
TorQ should support this workflow on Windows by using a directory move/copy strategy that works across volumes, so WDB
defaultwritedown mode can complete successfully when WDB and HDB are on different disks.Suggested Fix
Update the Windows implementation of
.os.renincode/common/os.qso that directory moves across volumes are supported.For example, the Windows path could detect when the source is a directory and use a Windows-compatible cross-volume directory move approach rather than relying on the current UNIX-style rename/move behavior.