GetByLabel with cloaking?

[ismangil]

I am experiencing some strange behaviour with regard to cloaking and labelling.

It seems getbylabel (I am using nant tasks, but will try to verify tomorrow with CLC) does not respect cloaking. I am labelling only the parent folder.

Also I am seeing high CPU usage on the DB during the getbylabel.

This particular folder is 500MB in total.

It's late now but I'll try to get some proper analysis tomorrow.

[ismangil]

I have now confirmed that with CLC 3.0.6 and nant vault tasks, GETLABEL does not respect cloaking. I also noticed that getlabel does not have any cloaking related option unlike GET.

This is tricky because labelling action itself also does not respect cloaking, meaning if you put a label on a parent folder which has one or more subfolders cloaked, it will still label it anyway.

So either way, if I use labelling and getlabel there is no easy way to cloak some folders.

Is this the expected behaviour?

I can modify the nant getbylabel task myself if you can give pointers on how to do it.

[ismangil]

It seems the cloak-related gets is handled internally by GetToNonWorkingFolder.

I could not see any additional parameters to set to respect cloaking for both GetByLabelToNonWorkingFolder_GetData (used in CLC) and GetLabeledFolderToNonWorkingFolder (used in nant task).

[dan]

Cloaking is a client side operation, whereas label is a server side operation, so applying a label should ignore cloaks (a label should not depend on a particular user's cloak settings).

However, a case could be made for respecting cloaks on the Get by Label. You are right that this would be handled in an OpsLib call, so it wouldn't request files from the server that are cloaked. Unfortunately, I don't believe there is much you can do to speed things up from the CLC code.

We'll add this as a feature request.

[ismangil]

Cloaking is a client side operation, whereas label is a server side operation, so applying a label should ignore cloaks (a label should not depend on a particular user's cloak settings).

OK, that makes sense.

However, a case could be made for respecting cloaks on the Get by Label. You are right that this would be handled in an OpsLib call, so it wouldn't request files from the server that are cloaked. Unfortunately, I don't believe there is much you can do to speed things up from the CLC code.

We'll add this as a feature request.

What if for now I modified the GetByLabelToNonWorkingFolder_GetData to be non recursive, and traverse the VaultClientFolder myself, checking if the folder is in the Cloaks collection or not? It seemed to work with my tree (no pins or shares or anything like that). Can you see any caveats?



Here's the excerpt from my modifications:

Code: Select all

.
.
if (labelStructure is VaultClientFolder)
{					
  StringCollection sc = new StringCollection();
  if (_ci.TreeCache.Cloaks != null && _args.RespectCloaks)
 {
	sc.AddRange(_ci.TreeCache.Cloaks.AllKeys);
 }
 GetLabeledFolderToNonWorkingFolderRecursive(
  (VaultClientFolder) labelStructure, _args.DestPath, mt, labelID,
   reposItem, labelSubItem, sc);
}
.
.
.
void GetLabeledFolderToNonWorkingFolderRecursive(VaultClientFolder vcfolder, string destPath, MergeType mt, long labelID, string reposItem, string labelSubItem, StringCollection cloaks)
{
  if (!cloaks.Contains(reposItem.ToLower()))
  {
	_ci.GetByLabelToNonWorkingFolder_GetData(
	  vcfolder, false, 
	 (mt == MergeType.OverwriteWorkingCopy) ? true : false, 
	_args.MakeWritable, 
	_args.SetFileTime, 
	destPath,
	null, 
	labelID,
	reposItem,
	labelSubItem);
			
	foreach (VaultClientFolder subfolder in vcfolder.Folders)
	{
	  GetLabeledFolderToNonWorkingFolderRecursive(
	    subfolder, 
	   destPath + "/" + subfolder.Name, 
	   mt, 
	   labelID, 
	   reposItem + "/" + subfolder.Name, 
	   labelSubItem, 
	   cloaks);
	}
  }
}

[dan]

That's a good idea - it might be a bit of work, but definitely what you want.

[ismangil]

Bumping up this old thread:

Using 3.5.1, it appears that getbylabel still doesn't respect cloaking.

Please make getbylabel respect cloaking!