Bug 192884 - [dstore][refresh] Files Shown Twice in New Filters
Summary: [dstore][refresh] Files Shown Twice in New Filters
Status: CLOSED FIXED
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.0 M3   Edit
Assignee: David McKnight CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-15 11:02 EDT by Kevin Doyle CLA
Modified: 2007-11-08 09:53 EST (History)
2 users (show)

See Also:


Attachments
patch to not use filter when determining previous elements (14.52 KB, patch)
2007-09-28 09:58 EDT, David McKnight CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Doyle CLA 2007-06-15 11:02:56 EDT
Sometimes after creating a filter the files are shown twice.  Refreshing the filter corrects the problem.

Steps to Reproduce:
Create new filters and check after each one to see if the files are displayed twice. I was playing with file types when I had this happen to me a couple times.  Try using file type .txt or txt.  I did this on a linux-dstore connection.

-----------Enter bugs above this line-----------
TM 2.0RC3 Testing
installation : eclipse-SDK-3.3RC4
RSE install  : RSE 2.0 RC3
java.runtime : Sun 1.5.0_11-b03
os.name:     : Windows XP, Service Pack 2
------------------------------------------------
Comment 1 Rupen Mardirossian CLA 2007-06-15 11:11:55 EDT
This has happened to me as well when I was trying to replicate the defect.  I had the filter to only show text files on a linux-dstore, it was showing zips and duplicates of .txt files.
Comment 2 David Dykstal CLA 2007-06-15 11:34:29 EDT
I have also seen this occasionally, but it is very intermittent. Have you noticed a pattern with respect to the underlying service or is it dstore specific?
Comment 3 David Dykstal CLA 2007-06-15 11:36:13 EDT
Dave --
I am assigning this to you, but your backlog is fairly large. We'll have to sift through this next week and reassign things to others.
Comment 4 Kevin Doyle CLA 2007-06-15 14:55:08 EDT
I've only seen this happen on dstore.  On the other connections it shows the files properly or doesn't show them at all.  Bug 192964 is open for that.
Comment 5 David McKnight CLA 2007-07-26 13:33:40 EDT
I wasn't able to reproduce this today.  Is this still something you hit?
Comment 6 Kevin Doyle CLA 2007-07-26 14:40:58 EDT
Yes, I hit this on my very first try.  Second try it didn't show the 2 files that matched *.txt and when I did a refresh it showed them twice.  Another Refresh showed them 3 times, etc.

Every try after I couldn't get the case where it showed doubles it just never showed any files that matched till I did a refresh then it showed double.

What I did:

1. Connect to dstore linux.
2. Find a folder and expand it.
3. Create a new filter for that folder with file types *.txt.  I'm assuming you have .txt files in the folder.  
--> Make sure you select the "Subset by file types" radio button since you can click the Select button but not select "Subset by file types".
4. Find the new filter and expand it.
Comment 7 David McKnight CLA 2007-09-28 09:56:42 EDT
The problem is in the miner.  When a query is done, we create a map of the previously created elements for the subject of the query to determine whether or not to create new elements (i.e. if there's already an element for a particular file, we don't recreate it).  However, we are only storing previous elements that match the filter (in this case ",txt").   First of all, we don't need to filter our list of previously created elements, and second, we are incorrectly comparing against the filter (via StringCompare(filter, name) which compares based on wildcards).
Comment 8 David McKnight CLA 2007-09-28 09:58:35 EDT
Created attachment 79391 [details]
patch to not use filter when determining previous elements

Since we don't need to filter our previous elements, the simple solution is just to not use the filter when creating that map.
Comment 9 Martin Oberhuber CLA 2007-09-28 14:36:05 EDT
So if it's in the miner, that would be specific to dstore, right?
Assigning 3.0 since 2.0.1 has been completed.
Comment 10 David McKnight CLA 2007-09-28 16:03:19 EDT
This is dstore-specific.  I've committed the fixes to the HEAD stream.
Comment 11 Kevin Doyle CLA 2007-11-08 09:53:54 EST
Verified fixed in I20071108.