Could not find a part of the path

[g18886]

Vault appears to be shortening a folder name and putting files under it. During a GETLABEL from CLI it errors trying to retrieve a file from a differently shortened folder name (unk vs. runk) . 'C:\Users\username\AppData\Local\Temp\vaultTmp\runk/DIRECTORY_1/DIRECTORY_2/ProjectFiles/datetime.txt exists. I tried the following workarounds:
1. Deleting cache and retrying- no joy
2. Deleting the bad directory 'C:\Users\username\AppData\Local\Temp\vaultTmp and retrying - no joy
3. Clearing the workspace and retrying- seems to work

Vault Standard 10.1.0 (1128)
This shouldn't be a merge issue as suggested viewtopic.php?p=83558&hilit=Could+not+f ... ath#p83558 since we're using -merge overwrite. The workspace (working folder) has previously been downloaded to. Clearing the workspace before downloading gets around this bug. I have not seen this issue with GET command.

Output with all 3 workarounds applied and successful retry of GETLABEL:

14:53:21 No working folders
14:53:21 Getting Sourcecode for Applications, Firmware Version 6940
14:53:21 Getting Application Version 6940
14:53:21 Getting these folders for $/Trunk
14:53:21 DIR: $/Trunk FC: Unknown
14:53:21 Executing "C:\Program Files (x86)\SourceGear\Vault Client\vault.exe" GETLABEL -ssl -host vault.server.com -repository REPOSITORY -user username -password ********* -makewritable -merge overwrite -setfiletime checkin -labelworkingfolder "C:\JK\workspace\B@4\Repository\Trunk "$/Trunk" "Firmware Version 6940"

14:53:39 "C:\Program Files (x86)\SourceGear\Vault Client\vault.exe" GETLABEL -ssl -host vault.server.com -repository REPOSITORY -user username -password **** -makewritable -merge overwrite -setfiletime checkin -labelworkingfolder "C:\JK\workspace\B@4\Repository\Trunk" "$/Trunk" "Firmware Version 6940"
14:53:39 <vault>
14:53:39 <error>
14:53:39 <exception>System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\username\AppData\Local\Temp\vaultTmp\unk/DIRECTORY_1/DIRECTORY_2/ProjectFiles/datetime.txt'.
14:53:39 at VaultClientIntegrationLib.GetOperations.performLabelGet(String objectPath, String label, String labelSubItem, String labelWorkingFolder, String destPath, GetOptions go)
14:53:39 at VaultClientIntegrationLib.GetOperations.ProcessCommandGetLabelToTempWorkingFolder(String objectPath, String label, String labelSubItem, GetOptions getOptions, String tmpWorkingFolder)
14:53:39 at VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
14:53:39 at VaultCmdLineClient.VaultCmdLineClient.Main(String[] args)</exception>
14:53:39 </error>
14:53:39 <result>
14:53:39 <success>False</success>
14:53:39 </result>
14:53:39 </vault>
14:53:39
14:53:39 Vault caching error
14:53:39 Clearing Vault cache and retrying download
14:53:39 deleting C:\Users\username\AppData\Local\SourceGear\Vault_1\Client on BUILD_AGENT <- Didn’t fix issue

14:53:45 cmd /c DIR "C:\Users\username\AppData\Local\SourceGear\Vault_1\Client"
14:53:45 Volume in drive C is CEF2-5DE3
14:53:45 Volume Serial Number is CEF2-5DE3
14:53:45
14:53:45 Directory of C:\Users\username\AppData\Local\SourceGear\Vault_1\Client
14:53:45
14:53:45 09/19/2023 02:53 PM <DIR> .
14:53:45 09/19/2023 02:53 PM <DIR> ..
14:53:45 09/19/2023 02:16 PM <DIR> C1E847F0-FD97-461B-8600-333D63E055E6
14:53:45 0 File(s) 0 bytes
14:53:45 3 Dir(s) 291,114,950,656 bytes free
14:53:45
14:53:45 deleting C:\Users\username\AppData\Local\Temp\vaultTmp on BUILD_AGENT <- Didn’t fix issue
14:53:45 cmd /c DIR "C:\Users\username\AppData\Local\Temp\vaultTmp"
14:53:45 File Not Found
14:53:45 Volume in drive C is CEF2-5DE3
14:53:45 Volume Serial Number is CEF2-5DE3
14:53:45
14:53:45 Directory of C:\Users\username\AppData\Local\Temp
14:53:45
14:53:45
14:53:45 deleting C:\JK\workspace\B@4\Repository\Trunk on BUILD_AGENT <- Fixed issue
14:53:46 cmd /c DIR "C:\JK\workspace\B@4\Repository"
14:53:46 Volume in drive C is CEF2-5DE3
14:53:46 Volume Serial Number is CEF2-5DE3
14:53:46
14:53:46 Directory of C:\JK\workspace\B@4\Repository
14:53:46
14:53:46 09/19/2023 02:53 PM <DIR> .
14:53:46 09/19/2023 02:53 PM <DIR> ..
14:53:46 0 File(s) 0 bytes
14:53:46 2 Dir(s) 291,295,637,504 bytes free
14:53:46
14:53:46 BUILD_PRODUCT BUILD_AGENT C:\JK\workspace\B@4\Repository\Trunk
14:53:46 Try#: 0, No errors, success:False, File Count: Not found, Expected: Unknown


Second try:
14:53:46 Executing "C:\Program Files (x86)\SourceGear\Vault Client\vault.exe" GETLABEL -ssl -host vault.server.com -repository REPOSITORY -user username -password ********* -makewritable -merge overwrite -setfiletime checkin -labelworkingfolder "C:\JK\workspace\B@4\Repository\Trunk "$/Trunk" "Firmware Version 6940"
…

14:57:07 BUILD_PRODUCT BUILD_AGENT C:\JK\workspace\B@4\Repository\Trunk
14:57:07 Try#: 1, No errors, success:True, File Count: 2519, Expected: Unknown
14:57:07 Successfully retrieved $/Trunk
14:57:07 Vault get took: 0:03:35
14:57:07 Successful downloads:
14:57:07 C:\JK\workspace\B@4\Repository\Trunk

[jclausius]

Just to verify, you are using a GETLABEL command from the command line, and by using the -LABELFOLDER option you have configured the command line client with a working folder of "C:\JK\workspace\B@4\Repository\Trunk" and the working folder is either empty or you have populated it with a previous GET command.

My theory is it sees files in there that it thinks it did not get, the Vault code goes into "resolve unknown files" mode. IT is in this mode, that Vault starts retrieving files to %TEMP%\vaultTmp\.

To avoid the issue, making sure the file was first populated with GET or is empty would be one work-around. Or if no file changes need to be committed back to the repository and you can verify there is no working folder set at $/Trunk/, perhaps using the -nonworkingfolder option would work instead.

Hopefully this helps.

[jclausius]

Note, when I say the Vault component sees files that it thinks it did not get, the Vault client has a client side cache for files it has retrieved and their state (checked out status list, time stamp, size, etc.). If you're running a builder where those pieces of the file cache file are not maintained between runs because the process doesn't really have a Windows %APPDATA% environment that keeps state between runs or perhaps that location is wiped because a VM rolls back, Vault will consider those files "Renegade."

It is in these Renegade states the Vault client code gets into the "resolve unknown files" section of the code and that is what is causing the problem seen in your situation.

[g18886]

Your reply wasn't clear, when will this be fixed?

[jclausius]

I've logged a bug report for the trimming issue for unknown files to investigate a fix for the problem. I'll report back on that once I know more.

In the meantime, hopefully some of the work-arounds I've provided will allow you to avoid unknown file resolution altogether.

[Tonya]

Hello again,

We wanted to reach out to let you know that we have a special build available to resolve the issue you reported. Please email support@sourcegear.com and we will provide you with additional details.

Thanks,

Tonya