Command Line Check Out fails but returns success

[dmurty]

Hi,

We are using Vault 4.0.6.15954 and have a nightly build script that builds all our projects and runs all the associated unit tests. We have noticed that if the build script tries to check out a file that is still exclusively locked by someone else that it does not fail on the check out but on the check in. The check out process returns the following message:
<vault>
<!--Check out failed for $/1 - Current Development/NET/Unit Tests/Database/HAS.DB: The file has been exclusively locked.-->
<!--Check out failed for $/1 - Current Development/NET/Unit Tests/Database/HAS.LOG: The file has been exclusively locked.-->
<!--Check out failed for $/1 - Current Development/NET/Unit Tests/Database/has.mlg: The file has been exclusively locked.-->
<result>
<success>True</success>
</result>
</vault>

Is there a way that we can get the result of this vault operation to return a failure if the files are already checked out?

Thanks

[lbauer]

Could you post an example of the script? Delete any passwords and server information.

[dmurty]

Here is the command line statement that is producing the successful checkout without actually checking out:

"C:\Program Files\SourceGear\Vault Client\vault.exe" -host www.rndstuff.com -user <OUR_USER_NAME> -password <OUR_PASSWORD> -repository "HealthCare Assistant" checkout "$/1 - Current Development/NET/Unit Tests/Database/HAS.db" "$/1 - Current Development/NET/Unit Tests/Database/HAS.log" "$/1 - Current Development/NET/Unit Tests/Database/HAS.mlg" -setfiletime modification -exclusive

Results:
<vault>
<!--Check out failed for $/1 - Current Development/NET/Unit Tests/Database/HAS.DB: The file has been exclusively locked.-->
<!--Check out failed for $/1 - Current Development/NET/Unit Tests/Database/HAS.LOG: The file has been exclusively locked.-->
<!--Check out failed for $/1 - Current Development/NET/Unit Tests/Database/has.mlg: The file has been exclusively locked.-->
<result>
<success>True</success>
</result>
</vault>

[lbauer]

We do have bug 13611 already logged for this, but we don't know when it might be fixed. I've added your comments and bumped it up in priority.