LABEL and GETLABEL with shared files

[Sourav]

The GETLABEL command on a shared file gives the following error.

C:\>vault.exe GETLABEL "$/my_repo/my_project/my_file.sql" "test.1"

<vault>
<error>
Could not find label "test.1" created at item "$/my_repo/my_project/my_file.sql".
</error>
<exception>
System.Exception: Could not find label "test.1" created at item "$/my_repo/my_project/my_file.sql".
at VaultCmdLineClient.VaultCmdLineClient.ProcessCommandGetLabel(String reposItem, String label, String labelSubItem)
at VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
at VaultCmdLineClient.VaultCmdLineClient.Main(String[] args)
</exception>
<result success="no" />
</vault>

This appears to be due to the fact that my shared file (my_file.sql) has two labels called "test.1" because the label was applied to the entire repository. If my_file.sql is shared 5 times and I apply a label to the repository, I get 5 identical labels. This seems like a bug in the LABEL and GETLABEL function for shared files.

Is there a workaround for this?

We are using:
Version Check: This Vault client is version 3.1.6.3658
Version Check: Your Vault server is version 3.1.6.3658

[lbauer]

If my_file.sql is shared 5 times and I apply a label to the repository, I get 5 identical labels. This seems like a bug in the LABEL and GETLABEL function for shared files.

This is not a bug -- if a shared file is labeled, all the shares carry the label.
Something else may be failing.

Can you get the label via GUI Client?

[Sourav]

if a shared file is labeled, all the shares carry the label.

Yes, each share will share the label. However, in a single label operation, shouldn't shared files only get labeled once, rather than multiple times based on the number of shares?

Just to clarify, I've attached a few screen shots to my example. The top shows my repo hierarchy. The middle shows the history. The bottom shows the labels.

I shared the file $/my_repo/my_project/my_file.sql with every my_share_x folder. The file now "exists" in 5 folders.
I then created label "label.1" at $/my_repo level.
I then created label "label.2" at $/my_repo/my_project level.

You can see that label.1 is displayed 5 times, but label.2 only once. Shouldn't the label function only label a shared file once?

Can you get the label via GUI Client?

Yes, get label via the GUI client works because you can select which label you want. However, all this is part of our build process and done through the vault.exe CLI. When label.1 is specified for GETLABEL, the exception occurs.

Any work around for this?

I also just noticed that the timestamps for the history does not match the timestamps for the label and that label.1 is listed later than label.2.

[jclausius]

n a single label operation, shouldn't shared files only get labeled once, rather than multiple times based on the number of shares?

I think there is a mis-understanding on the results of Show Labels. There are not three labels, just the one label applied to the top level folder.

When you invoke show labels on an object, it returns all instances of that object found in all labels. In the case of shares, if a folder containing three distinct shares is labeled, show labels on any one of those shares will display three different items, all found within the one single label.

The reson for this is the pin operation. Imagine, a file shared three ways in sub-items of a top level folder. However, within the sub-folder, each share is pinned to a different version. If a label is applied at the top level folder, and a get by label is executed on the file, which version should be retrieved? The version of the first pin? second pin? or third pin? Which would be "more correct"?

In order to handle this, a request must be more specific and ask for the distinct share as a "label path", as the version of the file will be different in each sub-path. So the GUI client and command line client must specify label paths in these cases.

vault.exe GETLABEL "$/my_repo/my_project/my_file.sql" "test.1"

As mentioned above, when you do a GETLABEL command in the command line client, you can also specify a label's sub-path. This is used specifically in the case of a GETLABEL asked against a shared file. Again, because of varying versions, a request must specify a label's sub-path so the server knows which specific version of the file the client is requesting.

Also, I noticed the command line was querying for the label "test.1". However, in the screen shots, it was labeled "label.1".

With that said, you may want to try something like

Code: Select all

vault.exe GETLABEL "$/my_repo/my_project/my_file.sql" "label.1" "my_repo/my_project/my_file.sql"

or

Code: Select all

vault.exe GETLABEL "$/my_repo/my_project/my_file.sql" "label.1" "my_repo/my_share_3/my_file.sql"

I also just noticed that the timestamps for the history does not match the timestamps for the label and that label.1 is listed later than label.2.

Currently, in Vault 3.1.8, the History Explorer uses date of the "version" the label was applied against. In Show Labels dialog, the timestamp of the actual label is used in the display.

[Sourav]

Jeff, thanks for clarifying how labels and linked files work.

I added the sub-path argument to our script and it now works as expected. I appreciate your help.