TIH 2009 problems with search

With TIH 11 I found a problem searching for files in a set of incrementals, that any file I searched for was found in every incremental even if it had not changed. See this original post.

Acronis support acknowledged this was a problem and said "most probably" it would be fixed in a future build of 11. That turned out not to be the case; but when 2009 came out they emailed me and assured me it was finally fixed.

Well, I have repeated the simple test I used originally, and discovered not only is this problem not fixed, but new problems have been introduced into the search system. Here is what I wrote up for Acronis:

------------------------------------------------------------------

Thank you very much for your continued support and your followup on this issue. However I am sorry to say that the original issue is not resolved at all. In fact the situation regarding searching incremental backups has become worse in some regards.

Let me describe the simple test I performed. I started by mounting an external USB drive as disk F: on my Windows Vista system. The disk had no files on it.

I created three folders named a, b, c. In each I created an empty text file a.txt, etc. so I then had a\a.txt, b\b.txt, c\c.txt on drive F:

I created an unscheduled task to back up partition F to a backup target on another drive, specifically to the path D:\Users\Michael\Work\projects\acronis\test.tib. I set the task to create a new archive and to perform an incremental backup.

I ran the task, creating test.tib. This I assume to be a full backup of the partition since no backup had yet been performed. Its size was about 600KB.

I edited two of the files, a\a.txt and b\b.txt and ran the task again. I got a file test2.tib whose size was about 33KB and which I assume to be an incremental backup of the partition.

I again edited two of the files, this time a\a.txt and c\c.txt and ran the task again. I got a file test3.tib, again about 33KB.

I again edited two of the files, this time b\b.txt and c\c.txt and ran the task again. I got a file test4.tib, again about 33KB.

Then I tried searching for files in these backups. I noted two issues with the new search procedure I will describe later. Concerning the issue at hand: what I expected to see is that each file would be found three times, once in the full backup and then in two of the three incrementals. Specifically, I expected that if I searched for a.txt, then b.txt, then c.txt I would find them as follows:

Code:

	Full		Incr 1		Incr 2		Incr 3
	----		------		------		------
a.txt	 X		  X		  X
b.txt	 X		  X		  		  X
c.txt	 X		  		  X		  X

Instead I found:

(1) Each file was found four times. Thus I conclude the original problem, "Searching incremental images always finds any file", is not resolved.

(2) The results as to where each file was found did not make any sense. For example, after searching for a.txt, the "Backup Content" tab said it was found four times in archive text4.tib with local paths C:\a.txt, D:\a.txt, E:a\txt, and F:\a.txt. Please see the attached screenshot.



In addition I found two issues which impact the utility of the new search function. The first may be "by design" but the second is clearly a bug.

(1) since backup locations have been removed there seems to be no way to restrict the search to a particular folder or folders of tib files. For example I have backups of my user partition in one folder and backups of my system partition in another. With Acronis 11 I made a backup location of the first folder but not of the second; thus I could search the backups of my user partitions only. With 2009 there appears to be no way to restrict the search to the backups of my user partition; it seems that every tib file on all my disks is included in the search. I do *not* want to search 100 gigabytes of system partition backups from the past six months every time I need to find a file from my user partition I modified last week!

(2) finding files by name and by using wildcards does not work correctly. To test this I removed all the files and folders from my test partition and created only the following files:

a.txt
aa.txt
aaa.txt
ab.txt
aba.txt
abb.txt
b.txt
bb.txt
bbb.txt

I created a full backup of the partition and searched it for such targets as "a.txt" and "?.txt". Here is a list of what I found and what I should have found:

Code:

Search		Should have found		Actually found
------		-----------------		--------------
a.txt		a.txt				a.txt
						aa.txt
						aaa.txt
						aba.txt

?.txt		a.txt, b.txt			(all 9 files)

??.txt		aa.txt, bb.txt		        aa.txt
						aaa.txt
						ab.txt
						aba.txt
						abb.txt
						bb.txt
						bbb.txt

aa.txt		aa.txt				aa.txt
						aaa.txt

ab.txt		ab.txt				ab.txt

ba.txt		(nothing)			aba.txt

 

I didn't test Files and Folders backup, but some whole disk images do appear in more than one place in Vista but not using XP.

I think this is partly due to the way Vista itself works. The main reason i beleive you have the 'C' drive entry is due to the newish database system. The entries which are in the temp files folder report themselves as complete images i.e. 80MB files (this is correct for the image I made), however I think these are placeholders and point to the correct place of the file. Mind you even though the other files physically exist (I mounted them) if you delete the file in the temp directory , the other existing files won't mount or restore.

Note these comments relate to beta2, I've yet to purchase the release version.

Colin

 

Hello MKairys,

Thank you for choosing Acronis Disk Backup Software.

We are sorry for delayed response.

Thank you for reporting that. Could you please let me know your Acronis request number (e.g. [Acronis #123456])? I will find out how the investigation of your issue is going. If you have not received the request number then please send us a Private Message containing your e-mail address.

Thank you.
--
Marat Setdikov

 

Thank you, my request number is 1228727. On 10/17 I received this reply:

Thank you for the detailed and very informative description.

Per your first test case i have created the task for our testers. I have no doubts that they will be able to reproduce it and have our developers fix it.

As for the fact that each file was found 4 times actually the size of it 0 bytes means that in this incremental backup it was not edited. However since this file was in the initial backup it should be found even with the zero size. This is the design and the rest of the issue will definitely be fixed by our developers.

The second part of the search using the wild cards is not very clear though maybe because of the initial formatting of the table of what was found and what should have been.

Could you please accompany the second issue with the screen shots too so that we could forward it to out testers as well?

I replied with the screen shots as requested, and added this comment:

Just to be sure my example was clear, please examine again the Backup Content tab (image a2.jpg in my initial mail). It shows:

a.txt D:\Users\Michael\Work]projects\acronis\test4.tib 0.019 KB ... C:\a\a.txt
a.txt D:\Users\Michael\Work]projects\acronis\test4.tib 0.038 KB ... D:\a\a.txt
a.txt D:\Users\Michael\Work]projects\acronis\test4.tib 0.038 KB ... E:\a\a.txt
a.txt D:\Users\Michael\Work]projects\acronis\test4.tib 0 KB ... F:\a\a.txt

There are two issues here, with Archive and Local Path.

That file was modified in incremental 1 and 2 but not incremental 3, so it should have been found in test.tib, test2.tib, test3.tib, but not test4.tib. Given your note about zero-byte files, I would expect the tab to show:

a.txt D:\Users\Michael\Work]projects\acronis\test.tib 0.019 KB ... E:\a\a.txt
a.txt D:\Users\Michael\Work]projects\acronis\test2.tib 0.038 KB ... E:\a\a.txt
a.txt D:\Users\Michael\Work]projects\acronis\test3.tib 0.038 KB ... E:\a\a.txt
a.txt D:\Users\Michael\Work]projects\acronis\test4.tib 0 KB ... E:\a\a.txt

... noting of course that the Local Path should be the same in all cases.

 

Hello MKairys,

We are sorry for delayed response.

Thank you for clarification. As I can see, the case is being worked upon by our experts. The information you sent has been received, and our experts will contact you as soon as possible.

Thank you.
--
Marat Setdikov

 

I repeated my test with 2009 update 9646 and found that the search results are still incorrect, although in a different way. Here is the test and the results.

I started by mounting an external USB drive as disk E: on my Windows Vista system. The disk had no files on it.

I created three folders named a, b, c. In each I created an empty text file a.txt, etc. so I then had three empty files a\a.txt, b\b.txt, c\c.txt on drive E:

I created an unscheduled task to back up partition E to a backup target on another drive, sepcifically to the path D:\Users\Michael\Test\test.tib. I set the task to create a new archive and to perform an incremental backup.

I ran the task, creating test.tib.

I edited two of the files, a\a.txt and b\b.txt and ran the task again, creating test2.tib.

I again edited two of the files, this time a\a.txt and c\c.txt, and ran the task again, creating test3.tib.

I again edited two of the files, this time b\b.txt and c\c.txt, and ran the task again, creating test4.tib.

Then I tried searching for files in these backups, noting that each file should be found in the full backup and should appear as modified in two of the three incrementals.

Assuming a given file will be found in each incremental but with a size of 0 if it is not modified, then I should expect to see the fillowing, where 0 indicates the file is found with size 0:

Code:

	test		test2		test3		test4
	----		------		------		------
a.txt	 X		  X		  X		  0
b.txt	 X		  X		  0  		  X
c.txt	 X		  0  		  X		  X

On the other hand if a given file is simply not found if it is not modified in a given incremental, then I should expect to see the following:

Code:

	test		test2		test3		test4
	----		------		------		------
a.txt	 X		  X		  X		   
b.txt	 X		  X		     		  X
c.txt	 X		     		  X		  X

Instead I saw the following:

Code:

	test		test2		test3		test4
	----		------		------		------
a.txt	 X		  X		  		  X
b.txt	 X		   		  X  		  X
c.txt	 		  X		  X		  X

If your earlier statement were true, then:

- a.txt should be found in test3 with size > 0 and in test4 with size = 0
- b.txt should be found in test2 with size > 0 and in test3 with size = 0

I note that c.txt was found in test2 with size = 0 so this is consistent with your earlier statement; but it is not correct that it was not found in test, the full archive.