Hi Karl,
I'm Guy, working Shai Shapira on that.
To answer your question "....why your build systems are using different drives for the Perforce data".
Our Windows build is comprised of a large amount of very small files (10^5). To make the cleanup faster after a build, we simply format that disk.
Moreover, a big chunk of the sources (~ 30GB) are SDKs that are rarely being changed. Instead of forced-syncing it on every build, we keep it in a separated drive, (non-forced) sync it and logically combined both drive into a one partition.
For that, we keep the root null.

The job below is a test for that matter.

Could u explain more about the workaround? How do we achieve that while still using the p4 plugin?
As a solution, can you introduce a checkbox "override root path" (default checked)?
Thanks
Hi shai_shap - Thanks for the feedback.
Can you give me an example of why your build systems are using different drives for the Perforce data so that I can pass that to the developers. Please also give me screen shots of your job definition and/or Jenkinsfile.
Jenkins usually controls where we should sync the files which is why p4-plugin is designed to overwrite the root with the location provided by Jenkins. However this does not work well with the model of different files on different Windows drive or fixed locations on the disk.
To work around the problem you could use multiple 'p4sync' or 'checkout' steps to each drive in a Jenkinsfile but would need to change 'ws' path before each sync. Another way is to use P4Groovy or a batch file and 'p4.exe' but you would lose the power of polling and change reporting.
Reproduction Steps:
(1) Setup a build slave on Windows.
(2) Create a workspace with a null root. For example:
This would sync the files from '//depot/project1/...' to 'C:\filestore\ws\JENKINS'.
(3) If you use the workspace behavior 'Static' we will try to sync the path 'null/...'. If you use Template the '\C:\' would be inserted into the path. Each way will cause a bad build.
See related job JENKINS-47005.