How do I fix "Unable to use Instant Scan for ..." error?

[haggis999]

Instant Scan is enabled in the Preferences for my installation of Retrospect 12.6.1.101, but I have only just noticed that the logs for my scheduled backup jobs have contained the warning "Unable to use Instant Scan for My Documents on MyData1 (G:)" for well over a year (I really must need new glasses). G: is a local NTFS drive on the same Windows 10 PC as Retrospect.

How do I fix this?

[jgowing]

Perhaps this Technote may help

[haggis999]

7 hours ago, jgowing said:

Perhaps this Technote may help

That link prompted me to check my C:\ProgramData\RetroISA\RetroISAScans folder. It was empty, which suggested that Instant Scan has never previously worked for me, even though the RetroInstantScanService was running. However, stopping and restarting that service did the trick. Running one of my scripted backup tasks caused the first scan to take place of the My Documents folder and running it again used this scan info to shorten the backup process.

Many thanks for pointing me in the right direction  ?

[haggis999]

I spoke too soon. Today's scheduled backup job for My Documents has once again generated a log containing the warning "Unable to use Instant Scan for My Documents on MyData1 (G:)". The RetroISAScans folder contains three .DAT files, two of which were overwritten by today's new scan. The smallest one (23kb) still carries yesterday's date.    

What might be causing this behaviour?

[Scillonian]

I noticed the same problem when Instant Scan first became available. There are certain special NTFS management files (Journal, MFT, etc) that cause the Instant Scan process to fail, delete the scan database, and abort any further scanning until the system is restarted. I opened a support case on this and basically the problem is these special files don't like Instant Scan 'looking' at them and generate a sharing violation which aborts the scan.

With each new release of Retrospect the Instant Scan scanning process has become more reliable and/or more tolerant of these special files. What I have noticed is some systems are more prone to this than others. The catch is you need to upgrade to the current version of Retrospect to get a more reliable Instant Scan.

[Scillonian]

If you look in the retroISA_log.utx file you will see entries similar to:

	[*] walkUSNjournal: err 0xc0000022 adding path for $TxfLog.blf fileFRN 0x100000000039e with parentFRN 0x100000000039b
	[!] walkUSNjournal: err 0xc0000022 for V:\
	[*] ISAVol::Exit: error -1073741790 (unknown), deleting scan file for "V:\"
	[*] ! ISAVolCon::IsaVolStopOne: stopped processing "V:\" on 2018-09-14 22:26:39

and

	[*] walkUSNjournal: err 0xc0000043 adding path for datastores.xml.tmp fileFRN 0x250000000005db with parentFRN 0x2a0000000015ed
	[!] walkUSNjournal: err 0xc0000043 for C:\
	[*] ISAVol::Exit: error -1073741757 (unknown), deleting scan file for "C:\"
	[*] ! ISAVolCon::IsaVolStopOne: stopped processing "C:\" on 2018-09-16 10:13:18

and

	[*] walkUSNjournal: err 0xc0000043 adding path for amd64_microsoft-windows-directui_31bf3856ad364e35_10.0.16299.492_none_c449a34c59896544 fileFRN 0xce000000000f4e with parentFRN 0xc480000000000f5
	[!] walkUSNjournal: err 0xc0000043 for C:\
	[*] ISAVol::Exit: error -1073741757 (unknown), deleting scan file for "C:\"
	[*] ! ISAVolCon::IsaVolStopOne: stopped processing "C:\" on 2018-10-16 21:46:11

The file $TxfLog.blf is one of the NTFS special files.

The [Windows] error codes translate to:

0xC0000022  STATUS_ACCESS_DENIED  --  A process has requested access to an object but has not been granted those access rights

0xC0000043  STATUS_SHARING_VIOLATION  --  A file cannot be opened because the share access flags are incompatible.

 

[haggis999]

9 minutes ago, Scillonian said:

The [Windows] error codes translate to:

0xC0000022  STATUS_ACCESS_DENIED  --  A process has requested access to an object but has not been granted those access rights

0xC0000043  STATUS_SHARING_VIOLATION  --  A file cannot be opened because the share access flags are incompatible.

Thanks for that information. I have exactly the same errors in my  retroISA_log.utx file.

I will just live with this problem for the time being, as I can't yet justify the expense of upgrading. It's been quite some time since a new version included features of any interest to me.