Agent root directories cannot be on different drives other than C: when using Windows

[kalibyrn]

Issue Details

Describe the bug
When changing the fsRoot setting for Windows-based Jenkins agents to a directory that is on a different drive, the agent cannot be launched. For instance, when we change from c:\jenkins to d:\jenkins, the agent emits this log:

[04/11/24 16:07:08] [SSH] Starting agent process: cd "d:\jenkins" && java  -jar remoting.jar -workDir d:\jenkins -jar-cache d:\jenkins/remoting/jarCache
Error: Unable to access jarfile remoting.jar
Agent JVM has terminated. Exit code=1

This is because the cd command in CMD shell does not change to the active drive (you do that by d: or c:, etc.), only the active directory on the drive that you specified.

When taking a look at the agent, I see that the d:\jenkins\remoting.jar file does indeed exist.

To Reproduce

1. Create an EC2 Fleet as you normally would
2. Set the fsRoot value (or "Jenkins Filesystem Root") setting to d:\jenkins
3. Cause the agent to launch (for example set "Minimum Spare Size" to 1 or something like that)
4. View the log as it is spinning up

Workaround
You can work around this issue by setting the "Prefix Start Agent Command" (or prefixStartSlaveCmd in configuration as code) to d: &&. That will cause the drive to be switched before the cd d:\jenkins command is run.

Suggestion
Perhaps use fully qualified paths when launching Jenkins or referencing anything in the fsRoot directory.

** Logs **
No logs from Jenkins server, only from the agent when it is being created:

[04/11/24 16:07:08] [SSH] Starting agent process: cd "d:\jenkins" && java  -jar remoting.jar -workDir d:\jenkins -jar-cache d:\jenkins/remoting/jarCache
Error: Unable to access jarfile remoting.jar
Agent JVM has terminated. Exit code=1

Environment Details

Plugin Version?
5.2.0

Jenkins Version?
2.440.2

Spot Fleet or ASG?
ASG

Label based fleet?
No (at least I don't believe so...)

Linux or Windows?
Windows

EC2Fleet Configuration as Code

   uniqueRemoteFSRoot: false
  - eC2Fleet:
      addNodeOnlyIfRunning: false
      alwaysReconnect: true
      cloudStatusIntervalSec: 10
      computerConnector:
        sSHConnector:
          credentialsId: "redacted"
          launchTimeoutSeconds: 60
          maxNumRetries: 50
          port: 22
          retryWaitTime: 30
          sshHostKeyVerificationStrategy: "nonVerifyingKeyVerificationStrategy"
      disableTaskResubmit: false
      executorScaler: "noScaler"
      fleet: "duffbot-windows-build-node-WindowsFleet"
      fsRoot: "d:\\jenkins"
      idleMinutes: 30
      initOnlineCheckIntervalSec: 15
      initOnlineTimeoutSec: 600
      labelString: "windows-build-node"
      maxSize: 10
      maxTotalUses: -1
      minSize: 0
      minSpareSize: 0
      name: "duffbot-windows-build-node-WindowsFleet"
      noDelayProvision: false
      numExecutors: 1
      privateIpUsed: true
      region: "us-east-1"
      restrictUsage: false
      scaleExecutorsByWeight: false
  - eC2Fleet:
      addNodeOnlyIfRunning: false
      alwaysReconnect: true
      cloudStatusIntervalSec: 10
      computerConnector:
        sSHConnector:
          credentialsId: "redacted"
          launchTimeoutSeconds: 60
          maxNumRetries: 50
          port: 22
          retryWaitTime: 30
          sshHostKeyVerificationStrategy: "nonVerifyingKeyVerificationStrategy"
      disableTaskResubmit: false
      executorScaler: "noScaler"
      fleet: "duffbot-windows-infratest-node-WindowsFleet"
      fsRoot: "d:\\jenkins"
      idleMinutes: 30
      initOnlineCheckIntervalSec: 15
      initOnlineTimeoutSec: 600
      labelString: "windows-infratest-node"
      maxSize: 10
      maxTotalUses: -1
      minSize: 0
      minSpareSize: 1
      name: "duffbot-windows-infratest-node-WindowsFleet"
      noDelayProvision: false
      numExecutors: 1
      privateIpUsed: true
      region: "us-east-1"
      restrictUsage: false
      scaleExecutorsByWeight: false

Anything else unique about your setup?
No