Context
The remote file-transfer machinery still uses naming inherited from ancient (pre-2.0.0, Sentry-era) code:
| Where |
Current name |
Transfer directory (WindowsTempShare.buildShareName(), used by ShellFileCopy) |
<windir>\Temp\SEN_ShareFor_<CLIENT-COMPUTER-NAME>$ |
Cluster temp subdirectory (WindowsTempShare.buildPathOnCluster()) |
<clusterShare>\Temp\SEN_TempFor_<CLIENT-COMPUTER-NAME> |
Unique output file names (WindowsRemoteProcessUtils.buildNewOutputFileName()) |
SEN_<CLIENT-COMPUTER-NAME>_<time>_<random> |
The SEN_ShareFor_...$ name (including the trailing $, the Windows hidden share convention) came from the old SMB-share implementation. Since 2.0.0 no share is created at all — files travel through the WinRM channel itself and land in a plain directory — so the name is both misleading and weird.
Proposal
Rename to a clear, modern scheme:
- Transfer directory:
<windir>\Temp\winrm-upload-<CLIENT-COMPUTER-NAME> (no trailing $)
- Cluster temp subdirectory:
<clusterShare>\Temp\winrm-upload-<CLIENT-COMPUTER-NAME>
- Output file names:
winrm-<CLIENT-COMPUTER-NAME>-<time>-<random>
The winrm-upload- prefix is deliberately short (13 characters, same length as SEN_ShareFor_):
- the MAX_PATH budget for the complete staging path (with a maximal 64-character client computer name) is unchanged;
- in the legacy
WindowsTempShare.getOrCreateShare() SMB flow (still public API), the share name stays under the 80-character share-name limit, which a longer prefix like winrm-java-upload- would exceed.
Compatibility notes
- Directories created by earlier versions (
SEN_ShareFor_<host>$) are not reused and no longer cleaned up by the 30-day purge; they can be deleted manually.
- Hosts hardened with per-directory ACLs (see Preparing the Windows Host) must grant write access on the new path.
- Documentation (
file-transfers.md, preparing-the-host.md) and Javadoc must be updated accordingly.
Context
The remote file-transfer machinery still uses naming inherited from ancient (pre-2.0.0, Sentry-era) code:
WindowsTempShare.buildShareName(), used byShellFileCopy)<windir>\Temp\SEN_ShareFor_<CLIENT-COMPUTER-NAME>$WindowsTempShare.buildPathOnCluster())<clusterShare>\Temp\SEN_TempFor_<CLIENT-COMPUTER-NAME>WindowsRemoteProcessUtils.buildNewOutputFileName())SEN_<CLIENT-COMPUTER-NAME>_<time>_<random>The
SEN_ShareFor_...$name (including the trailing$, the Windows hidden share convention) came from the old SMB-share implementation. Since 2.0.0 no share is created at all — files travel through the WinRM channel itself and land in a plain directory — so the name is both misleading and weird.Proposal
Rename to a clear, modern scheme:
<windir>\Temp\winrm-upload-<CLIENT-COMPUTER-NAME>(no trailing$)<clusterShare>\Temp\winrm-upload-<CLIENT-COMPUTER-NAME>winrm-<CLIENT-COMPUTER-NAME>-<time>-<random>The
winrm-upload-prefix is deliberately short (13 characters, same length asSEN_ShareFor_):WindowsTempShare.getOrCreateShare()SMB flow (still public API), the share name stays under the 80-character share-name limit, which a longer prefix likewinrm-java-upload-would exceed.Compatibility notes
SEN_ShareFor_<host>$) are not reused and no longer cleaned up by the 30-day purge; they can be deleted manually.file-transfers.md,preparing-the-host.md) and Javadoc must be updated accordingly.