Tag reports in Retrospect 10 - looks like they still don't work

[eeolson]

It looks to me like tag reports still don't work. At least when I create a report that has "Tags Contain...", "Tags begin with" etc., nothing shows up in the report. Can anyone confirm this. I'd like to think that of course they have fixed this by now, but I can't find any evidence that they have.

 

It would be nice to list what items have what tags... right?

 

thanks,

 

- eric

[bdunagan]

Thanks for the report. This issue (bug 3385) is fixed in the upcoming release.

[eeolson]

Just installed 10.1 - this is definitely NOT fixed. The problem with tags not displaying in the Tags tab of the Sources pane is still there - you still have to "nudge" the display to see tags (see below). Also, the reports simply do not work - tags Contain, Tags begin with, Tags are not empty - *nothing* shows up in the report - no, wait - "tags are not blank" report showed one item - an item with - you guessed it - no tags (sigh).

 

Another user gave the hint on how to display a volume's tag: Create a dummy tag for this purpose (mine is "z_Unused_Tag"), view a volume (no tags show), tick the dummy tag (I guess this just changes the volume's tag state), click off the volume and then back on it - it should show the dummy tag ticked, as well as the real tag.

[David W Lee]

We see your Support ticket and Engineering is looking into this escalated issue.

[henry-in-florida]

We see your Support ticket and Engineering is looking into this escalated issue.

Mr. Lee,

I just found a similar issue with tags not showing up after they are set, even though they do operate in my version (10.1 Build 221). Apparently there is a work-around posted somewhere here. Does it help you if I restate the work-around in the way it works for me?

1. Create a dummy tag, simply for purposes of checking existing ones.
   
2. Close and reopen Retrospect.
   
3. Open the Source window.
   
4. Tick a Volume.
   
5. No volumes show tags checked (even though you suspect they were previously).
   
6. Tick the dummy tag, then UNTICK it.
   
7. Violá! The actual tags are then shown on that volume. Since the dummy tag was un-ticked in the previous step it is not shown, being of use only to 'reveal' the invisible tag status.
   
8. Closing and reopening Retrospect will cause this situation to recur, but status of tags will stick while the application remains open, once showing.
   
9. Repeat Steps 1-5 above when (not if) the situation recurs.
   
10. FYI, the actual tagged items are never further shown in the backup windows, even though they do result in a backup. You may want to more fully describe the actual operation of tags in the User Manual when this bug gets squashed.
    

I think that the above may give you specific clues to the repair of this bug.

 

Regards,

 

Henry

Edited April 7, 2013 by henry-in-florida

[David W Lee]

Thank you Henry.

[eeolson]

Henry-in-FLA...

 

Your method works, and saves a step over mine, however:

- sometimes you have to pause a bit after ticking the dummy tag, and then unticking

- sometimes it takes more than one tick/untick cycle to get the tag to show.

 

Now, if there was something I could tick and untick to get a tag *report* to show. I'd like a list of all the machines I have tagged for AfterHrsBackup, and those tagged for 24HrBackup.

[eeolson]

oh... OH! I just gleaned from another post that tag reporting only works if the top-level *source* is tagged, not if a favorite folder is tagged. This, obviously is fairly useless considering how rare it is to designate an entire source for backup. I hope Retrospect will address this shortcoming.

 

So, to clarify, I can get a tag report to work IF the entire source is tagged.

[henry-in-florida]

Thank you Henry.

Do you have an ETA on the fix for this issue, as it's been over a month? I am clearly not alone in reporting this bug. Also found an update to my complaint and those of others on these pages:

• If you mistakenly check the wrong box then uncheck it, even after unchecking, after a shortly delay, proactive events that run next will attempt to backup to that tagged item. And thus begins a new cycle of pain.
  
• Wrongly checked items /ontinue to run until manually stopped.
  
• After being stopped, the wrongly checked and unchecked items do not recur as long as the previous procedure was used to verify the status.
  
• There is no workaround to see a proper report of assigned tags to all sources, like a tag report that reliably shows the tag assignments
  

 

Regards,

 

H