Compare folders and filter on one file type

[mikes1p]

I want to compare our users PST files on our primary file server and a secondary server, I do not care to see any other files. Each user has a folder, the PST file is usually in a folder named "Email" but not always.

I tried comparing two user folders on the primary server just to keep it simple. I set a File Filter to "*.pst" (without the quotes) but no luck, UltraCompare only shows a few folders but does not show any PST files, if I remove the filter it shows all files. If I set the filter to "*.txt" I see only txt files. What am I missing? There are no Folder Mode "Hide" filters selected.

Thanks
Mike S

[Mofi]

I don't have a problem using filter *.pst with a basic folder compare with UltraCompare Professional v6.10.0.1006 running on Windows XP SP3 with an account which has administrative privileges on local drives.

Which version of UltraCompare do you use?
Which operating system do you use?
Which folder compare do you run (basic, full, smart)?

[mikes1p]

I am running XP Pro SP3 as Domain Administrator (full access to local and network paths) and UC 6.10.0.1006

If a place two test PST files in different folders on my local HD it works with *.pst using Smart mode. I did this just to rule out network/permissions issues

If I use a UNC path or a mapped drive that I have full permissions to:
Set Filter works with *.log, *.ini, *.xls etc
Set Filter DOES NOT work with *.pst
I verified that I have full permissions to the file and folders in the path to it
I tried Basic, Smart, Full methods with Recursive Compare checked

I can send an 8mb AVI screen recording if you care, the forum app wouldn't let me upload it
Thanks
Mike

[pietzcker]

Just a wild guess here - how big are the .pst files? Could that be a problem?

[mikes1p]

I tried small files that worked on my local HD on the mapped drive and it still didnt work
Thanks for the suggestion
Mike S

[Mofi]

I suggest to download and unpack Filemon from SysInternals to a local temp directory. Run Filemon and set the include filter to include only log lines containing the 2 root folder names of your folder compare. Then run the folder compare in UC and look into the file access log of Filemon. Maybe you can see if UC makes something wrong or if there is a permission/access problem.

[mikes1p]

Good idea makes sense. Here is the FileMon output when Include Filter = z:\*\email

Code: Select all

UC Set Filter *.pst
1   8:55:04 AM   uc.exe:5220   OPEN   Z:\mpaul\Email\   SUCCESS   Options: Open Directory  Access: 00100001   
2   8:55:04 AM   uc.exe:5220   OPEN   Z:\pbarron\Email\   SUCCESS   Options: Open Directory  Access: 00100001   
3   8:55:04 AM   uc.exe:5220   DIRECTORY   Z:\pbarron\Email\   SUCCESS   FileBothDirectoryInformation: *   
4   8:55:04 AM   uc.exe:5220   DIRECTORY   Z:\mpaul\Email\   SUCCESS   FileBothDirectoryInformation: *   
5   8:55:04 AM   uc.exe:5220   DIRECTORY   Z:\mpaul\Email\   SUCCESS   FileBothDirectoryInformation   
6   8:55:04 AM   uc.exe:5220   DIRECTORY   Z:\mpaul\Email\   NO MORE FILES   FileBothDirectoryInformation   
7   8:55:04 AM   uc.exe:5220   CLOSE   Z:\mpaul\Email\   SUCCESS      
8   8:55:04 AM   uc.exe:5220   DIRECTORY   Z:\pbarron\Email\   SUCCESS   FileBothDirectoryInformation   
9   8:55:04 AM   uc.exe:5220   DIRECTORY   Z:\pbarron\Email\   NO MORE FILES   FileBothDirectoryInformation   
10   8:55:04 AM   uc.exe:5220   CLOSE   Z:\pbarron\Email\   SUCCESS      

UC Set Filter <blank>
11   8:55:17 AM   uc.exe:5220   OPEN   Z:\mpaul\Email\   SUCCESS   Options: Open Directory  Access: 00100001   
12   8:55:17 AM   uc.exe:5220   OPEN   Z:\pbarron\Email\   SUCCESS   Options: Open Directory  Access: 00100001   
13   8:55:17 AM   uc.exe:5220   DIRECTORY   Z:\mpaul\Email\   SUCCESS   FileBothDirectoryInformation: *   
14   8:55:17 AM   uc.exe:5220   DIRECTORY   Z:\pbarron\Email\   SUCCESS   FileBothDirectoryInformation: *   
15   8:55:17 AM   uc.exe:5220   DIRECTORY   Z:\mpaul\Email\   SUCCESS   FileBothDirectoryInformation   
16   8:55:17 AM   uc.exe:5220   DIRECTORY   Z:\mpaul\Email\   NO MORE FILES   FileBothDirectoryInformation   
17   8:55:17 AM   uc.exe:5220   CLOSE   Z:\mpaul\Email\   SUCCESS      
18   8:55:17 AM   uc.exe:5220   DIRECTORY   Z:\pbarron\Email\   SUCCESS   FileBothDirectoryInformation   
19   8:55:17 AM   uc.exe:5220   DIRECTORY   Z:\pbarron\Email\   NO MORE FILES   FileBothDirectoryInformation   
20   8:55:17 AM   uc.exe:5220   CLOSE   Z:\pbarron\Email\   SUCCESS      
21   8:55:17 AM   uc.exe:5220   OPEN   Z:\mpaul\Email\   SUCCESS   Options: Open  Access: Read-Attributes   
22   8:55:17 AM   uc.exe:5220   QUERY INFORMATION   Z:\mpaul\Email\   SUCCESS   FileBasicInformation   
23   8:55:17 AM   uc.exe:5220   CLOSE   Z:\mpaul\Email\   SUCCESS      
24   8:55:17 AM   uc.exe:5220   OPEN   Z:\mpaul\Email\minda.pst   SUCCESS   Options: Open  Access: Read-Attributes   
25   8:55:17 AM   uc.exe:5220   QUERY INFORMATION   Z:\mpaul\Email\minda.pst   SUCCESS   FileBasicInformation   
26   8:55:17 AM   uc.exe:5220   CLOSE   Z:\mpaul\Email\minda.pst   SUCCESS      
27   8:55:17 AM   uc.exe:5220   OPEN   Z:\pbarron\Email\Paul.pst   SUCCESS   Options: Open  Access: Read-Attributes   
28   8:55:17 AM   uc.exe:5220   QUERY INFORMATION   Z:\pbarron\Email\Paul.pst   SUCCESS   FileBasicInformation   
29   8:55:17 AM   uc.exe:5220   CLOSE   Z:\pbarron\Email\Paul.pst   SUCCESS      
30   8:55:17 AM   uc.exe:5220   OPEN   Z:\mpaul\Email\   SUCCESS   Options: Open  Access: Read-Attributes   
31   8:55:17 AM   uc.exe:5220   QUERY INFORMATION   Z:\mpaul\Email\   SUCCESS   FileBasicInformation   
32   8:55:17 AM   uc.exe:5220   CLOSE   Z:\mpaul\Email\   SUCCESS      
33   8:55:17 AM   uc.exe:5220   OPEN   Z:\mpaul\Email\   SUCCESS   Options: Open  Access: Read-Attributes   
34   8:55:17 AM   uc.exe:5220   QUERY INFORMATION   Z:\mpaul\Email\   SUCCESS   FileBasicInformation   
35   8:55:17 AM   uc.exe:5220   CLOSE   Z:\mpaul\Email\   SUCCESS      

[Mofi]

Okay, I have found the problem and it is a bug of UltraCompare. It does not matter if local or network directories are compared. It is the combination of using a file filter with running a recursive (basic) folder compare. To reproduce your problem I have done following:

I created on my harddisk in a temp folder the directories Test1 and Test2, copied 2 files into both folders. That looked on my harddisk as follows:

F:\Temp\Test1\Test1.txt
F:\Temp\Test1\Test2.txt
F:\Temp\Test2\Test1.txt
F:\Temp\Test2\Test2.txt

The files Test2.txt are identical in both directories, the files Test1.txt are different.

Now I started UltraCompare Professional v6.10.0.1006 and ran a recursive basic folder compare with standard options and the result was correct. Next I specified *.txt at Options - Set Filter and the result was correct again.

Now I created in both directories a subdirectory and moved the files into the subdirectories. That looked on my harddisk as follows:

F:\Temp\Test1\SubDir\Test1.txt
F:\Temp\Test1\SubDir\Test2.txt
F:\Temp\Test2\SubDir\Test1.txt
F:\Temp\Test2\SubDir\Test2.txt

I ran again the basic folder compare with filter *.txt as filter on F:\Temp\Test1\ versus F:\Temp\Test2\ and I did not get the correct result. I could see the same as you in Filemon. UltraCompare does not access any *.txt in the subdirectories.

I opened Options - Set Filter and removed *.txt. After closing the dialog with OK UltraCompare displayed immediately the correct and expected result.

So there is definitely a bug with recursive folder compare of any type (basic, full, smart) if additionally a file filter is specified.

I reported this issue with a bug report email to IDM and IDM support could reproduce that issue and confirmed it as bug.

[mikes1p]

Well I'm glad it wasn't me!! I guess I'll have to wait for a bug fix

Mike S

[Mofi]

This issue was fixed with UC Prof. v6.20.