GETLABEL on Shared File
Moderator: SourceGear
GETLABEL on Shared File
We have the following error when attempting to do a GETLABEL on a shared file from the command line:
<vault>
<error>
<exception>System.Exception: Could not find label "LCLINSTALL_12000" created at item "$/VL/Release/v12/L4W12000/work/x_win95/x_lansa/src/lansaver.h".
at VaultClientIntegrationLib.GetOperations.performLabelGet(String objectPath, String label, String labelSubItem, String labelWorkingFolder, String destPath, GetOptions go)
at VaultClientIntegrationLib.GetOperations.ProcessCommandGetLabelToLocationOutsideWorkingFolder(String objectPath, String label, String labelSubItem, GetOptions getOptions, String destPath)
at VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
at VaultCmdLineClient.VaultCmdLineClient.Main(String[] args)</exception>
</error>
<result>
<success>False</success>
</result>
</vault>
Searching through these forums I found the release notes for V 4.1.4 which include the following fix:
* CLC GETLABEL fails when an item has been shared two or more times inside the label
We are on V 4.1.3 but we do have one client which is 4.1.4. We can reproduce this error on the 4.1.4 client also. We suspect we would need to upgrade the Vault Server to 4.1.4 for this error to be fixed. Could you please confirm that this was a Server side fix. If it was then we'll endeavour to upgrade as soon as possible.
Thanks
Anthony.
<vault>
<error>
<exception>System.Exception: Could not find label "LCLINSTALL_12000" created at item "$/VL/Release/v12/L4W12000/work/x_win95/x_lansa/src/lansaver.h".
at VaultClientIntegrationLib.GetOperations.performLabelGet(String objectPath, String label, String labelSubItem, String labelWorkingFolder, String destPath, GetOptions go)
at VaultClientIntegrationLib.GetOperations.ProcessCommandGetLabelToLocationOutsideWorkingFolder(String objectPath, String label, String labelSubItem, GetOptions getOptions, String destPath)
at VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
at VaultCmdLineClient.VaultCmdLineClient.Main(String[] args)</exception>
</error>
<result>
<success>False</success>
</result>
</vault>
Searching through these forums I found the release notes for V 4.1.4 which include the following fix:
* CLC GETLABEL fails when an item has been shared two or more times inside the label
We are on V 4.1.3 but we do have one client which is 4.1.4. We can reproduce this error on the 4.1.4 client also. We suspect we would need to upgrade the Vault Server to 4.1.4 for this error to be fixed. Could you please confirm that this was a Server side fix. If it was then we'll endeavour to upgrade as soon as possible.
Thanks
Anthony.
Re: GETLABEL on Shared File
Your error message demonstrates that your command line client is not 4.1.4. In 4.1.4, the exception message is included after the item path.
What does the Vault client return for its version when you use the
Could you please post the error message from a 4.1.4 command line client?
What does the Vault client return for its version when you use the
Code: Select all
vault help
Subscribe to the Fortress/Vault blog
Re: GETLABEL on Shared File
G'day Jeremy,
yes your correct, that error message was from my client which is 4.1.3. Here is the error message from the 4.1.4 client.
The command we used is:
vault getlabel -user xxxx -password xxxx -repository xxxx -host xxxx -verbose -nonworkingfolder c:\temp\x_win95\x_lansa\src "$/VL/Release/v12/L4W12000/work/x_win95/x_lansa/src/lansaver.h" "LCLINSTALL_12000"
<vault>
<error>
<exception>System.Exception: Could not find label "LCLINSTALL_12000" created at item "$/VL/Release/v12/L4W12000/work/x_win95/x_lansa/src/lansaver.h". 1902
: FailInvalidLabel
at VaultClientIntegrationLib.GetOperations.performLabelGet(String objectPath,
String label, String labelSubItem, String labelWorkingFolder, String destPath,
GetOptions go)
at VaultClientIntegrationLib.GetOperations.ProcessCommandGetLabelToLocationOu
tsideWorkingFolder(String objectPath, String label, String labelSubItem, GetOpti
ons getOptions, String destPath)
at VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
at VaultCmdLineClient.VaultCmdLineClient.Main(String[] args)</exception>
</error>
<result>
<success>False</success>
</result>
</vault>
>vault help
<vault>
<usage>SourceGear Vault Command Line Client 4.1.4.18402Copyright (c) 2003-2008
SourceGear LLC. All Rights Reserved.
Regards,
Anthony.
yes your correct, that error message was from my client which is 4.1.3. Here is the error message from the 4.1.4 client.
The command we used is:
vault getlabel -user xxxx -password xxxx -repository xxxx -host xxxx -verbose -nonworkingfolder c:\temp\x_win95\x_lansa\src "$/VL/Release/v12/L4W12000/work/x_win95/x_lansa/src/lansaver.h" "LCLINSTALL_12000"
<vault>
<error>
<exception>System.Exception: Could not find label "LCLINSTALL_12000" created at item "$/VL/Release/v12/L4W12000/work/x_win95/x_lansa/src/lansaver.h". 1902
: FailInvalidLabel
at VaultClientIntegrationLib.GetOperations.performLabelGet(String objectPath,
String label, String labelSubItem, String labelWorkingFolder, String destPath,
GetOptions go)
at VaultClientIntegrationLib.GetOperations.ProcessCommandGetLabelToLocationOu
tsideWorkingFolder(String objectPath, String label, String labelSubItem, GetOpti
ons getOptions, String destPath)
at VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
at VaultCmdLineClient.VaultCmdLineClient.Main(String[] args)</exception>
</error>
<result>
<success>False</success>
</result>
</vault>
>vault help
<vault>
<usage>SourceGear Vault Command Line Client 4.1.4.18402Copyright (c) 2003-2008
SourceGear LLC. All Rights Reserved.
Regards,
Anthony.
Re: GETLABEL on Shared File
My best guess is that the label you're searching for has not been applied to the object. Can you verify that you see it in the GUI client?
Subscribe to the Fortress/Vault blog
Re: GETLABEL on Shared File
Its definitely got that LABEL. I've attached the result of the "Show Labels" on that file.
Some other points in regards to this:
1. if I run that same command but specify the directory (ie. "$/VL/Release/v12/L4W12000/work/x_win95/x_lansa/src") rather than the specific file then lansaver.h is retrieved along with all the other files (both shared and non-shared) in that directory.
2. If I run the same command and specify a file from that same directory that isn't shared then the file IS retrieved without error.
3. If I run the same command and specify any other shared file from that same directory then the error occurs.
So it definitely appears to be a problem with Shared files and GETLABEL.
Some other points in regards to this:
1. if I run that same command but specify the directory (ie. "$/VL/Release/v12/L4W12000/work/x_win95/x_lansa/src") rather than the specific file then lansaver.h is retrieved along with all the other files (both shared and non-shared) in that directory.
2. If I run the same command and specify a file from that same directory that isn't shared then the file IS retrieved without error.
3. If I run the same command and specify any other shared file from that same directory then the error occurs.
So it definitely appears to be a problem with Shared files and GETLABEL.
- Attachments
-
- Show Labels Result
- vault1.JPG (29.8 KiB) Viewed 5961 times
Re: GETLABEL on Shared File
Anthony,
I'm going to butt in on Jeremy. Could you answer some quick questions:
a) Do you have the server log from around the time of a CLC GET on the label? If so, could you post it or mail it to support at sourcegear dot com?
b) The file is shared. Are there any pinned folder paths along the way to that share or other shares?
c) Can you look at all three spots of the share, and do a history for the files within the GUI or CLC? Are the results the same?
d) If you run a CLC GETLABEL on the other shared locations do any of those work?
Thanks,
Jeff
I'm going to butt in on Jeremy. Could you answer some quick questions:
a) Do you have the server log from around the time of a CLC GET on the label? If so, could you post it or mail it to support at sourcegear dot com?
b) The file is shared. Are there any pinned folder paths along the way to that share or other shares?
c) Can you look at all three spots of the share, and do a history for the files within the GUI or CLC? Are the results the same?
d) If you run a CLC GETLABEL on the other shared locations do any of those work?
Thanks,
Jeff
Jeff Clausius
SourceGear
SourceGear
Re: GETLABEL on Shared File
G'day Jeff,
the answers to your questions...
a)
----16/12/2009 8:39:31 AM ...--SSL Disabled Login
----16/12/2009 8:39:33 AM ...--SSL Disabled GetLabelStructure returned: FailInvalidLabel
----16/12/2009 8:39:33 AM ...--SSL Disabled Logout
b) No
c) Yes. Show History done through the GUI shows history is the same in all three spots.
d) No. All fail with the same error. I tested this on both a 4.1.3 & 4.1.4 client.
Some more info if it will help diagnose the problem. If I apply a Label low enough in the directory structure so that it is only applied to one of the shared locations then I can use that label to get out the shared file.
Regards,
Anthony
the answers to your questions...
a)
----16/12/2009 8:39:31 AM ...--SSL Disabled Login
----16/12/2009 8:39:33 AM ...--SSL Disabled GetLabelStructure returned: FailInvalidLabel
----16/12/2009 8:39:33 AM ...--SSL Disabled Logout
b) No
c) Yes. Show History done through the GUI shows history is the same in all three spots.
d) No. All fail with the same error. I tested this on both a 4.1.3 & 4.1.4 client.
Some more info if it will help diagnose the problem. If I apply a Label low enough in the directory structure so that it is only applied to one of the shared locations then I can use that label to get out the shared file.
Regards,
Anthony
Re: GETLABEL on Shared File
Anthony,
Thanks for the info. Please give me some time. I'm going to get some more people involved to see if we can reproduce the problem here.
Thanks for the info. Please give me some time. I'm going to get some more people involved to see if we can reproduce the problem here.
Jeff Clausius
SourceGear
SourceGear
Re: GETLABEL on Shared File
ante,
OK. I've gone through this, and it appears the problem is related to the arguments.
When you GET a specific instance of an item which is shared within a label, the server does not know which item you are requesting. This is important especially in the case of pins as the version of the shared file is not necessarily consistent throughout a label.
In cases like this, a "label path" argument is required to resolve the path.
$/VL/Release/v12/L4W12000/work/x_win95/x_lansa/src
"$/VL/Release/v12/L4W12000/work/x_win95/x_lansa/src/lansaver.h" "LCLINSTALL_12000"
For example, the following should work from the command line:
vault GETLABEL -user xxxx -password xxxx -repository xxxx -host xxxx -verbose -nonworkingfolder c:\temp\x_win95\x_lansa\src "$/VL/Release/v12/L4W12000/work/x_win95/x_lansa/src/lansaver.h" "LCLINSTALL_12000" "work/x_win95/x_lansa/src/lansaver.h"
What happens here is the label structure for LCLINSTALL_12000 is retrieved, if multiple instances of the ID of lansaver.h are found, the path (from where the label was created) is used to resolve the shared file conflict, thus getting the correct lansaver.h
OK. I've gone through this, and it appears the problem is related to the arguments.
When you GET a specific instance of an item which is shared within a label, the server does not know which item you are requesting. This is important especially in the case of pins as the version of the shared file is not necessarily consistent throughout a label.
In cases like this, a "label path" argument is required to resolve the path.
$/VL/Release/v12/L4W12000/work/x_win95/x_lansa/src
"$/VL/Release/v12/L4W12000/work/x_win95/x_lansa/src/lansaver.h" "LCLINSTALL_12000"
For example, the following should work from the command line:
vault GETLABEL -user xxxx -password xxxx -repository xxxx -host xxxx -verbose -nonworkingfolder c:\temp\x_win95\x_lansa\src "$/VL/Release/v12/L4W12000/work/x_win95/x_lansa/src/lansaver.h" "LCLINSTALL_12000" "work/x_win95/x_lansa/src/lansaver.h"
What happens here is the label structure for LCLINSTALL_12000 is retrieved, if multiple instances of the ID of lansaver.h are found, the path (from where the label was created) is used to resolve the shared file conflict, thus getting the correct lansaver.h
Jeff Clausius
SourceGear
SourceGear