Compare folders and filter on one file type

mikes1p · Feb 09, 2009#12009-02-09T23:59+00:00

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 · Feb 10, 2009#22009-02-10T09:05+00:00

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 · Feb 10, 2009#32009-02-10T18:27+00:00

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 · Feb 10, 2009#42009-02-10T21:23+00:00

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

mikes1p · Feb 10, 2009#52009-02-10T23:09+00:00

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 · Feb 11, 2009#62009-02-11T09:02+00:00

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 · Feb 12, 2009#72009-02-12T17:02+00:00

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

[/size]

Mofi · Feb 13, 2009#82009-02-13T09:09+00:00

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 · Feb 13, 2009#92009-02-13T16:12+00:00

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

Mike S

Mofi · Apr 03, 2009#102009-04-03T08:22+00:00

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