Jump to content

InCD and Retrospect, are they not playing nice together?


kaikow

Recommended Posts

I've mentioned this problem in other threads, but I believe it now deserves its own thread as it has become too easy to reproduce, or so it seems.

 

With Win 2000 SP 4, Retrospect 6.5 and InCD 3.5.24.0, I appear to be seeing the following behavior:

 

1. I periodically save the Retrospect catalog files to CD-RW, along with the config65.dat file.

 

2. After copyimg the files to the CD-RW and removing the CD-RW media, I am finding that if I run Retrospect without rebooting the system, a BSOD occurs not too long after I start running a Retrospect job. This has occurred the last 3 times I copied the files to the CD-RW, followed by running Retrospect. Note that Retrospect does not have to be run right away fpr the problem to occur.

 

My theory is that InCD is somehow preventing Retrospect from modifying the Retrospect catalog files because the BSOD seems to occur at a point at which I would expect that Retrospect is trying to update the catalog.

 

If I reboot the system, no such problem.

 

I cannot try this with InCD 4 because InCD 4 has a serious bug, so I'm stuck with InCD 3.

 

I expect that the cause of the problem may be InCD, perhaps, Retrospect could do more error handling to reduce the chance of an error occurring when accessing the catalog files.

Link to comment
Share on other sites

Hi Howard,

 

Do you get a blue screen any time you run Retrospect after running InCD? Please test this.

 

The fact that you have made extra copies of the catalog files on the CDRW should make no difference in Retrospect. If you do not use your CDRW drive as a backup device it is a good Idea to ignore it in the Retrospect environment window.

 

Are you actively using the catalog files stored on your CDRW drive?

Nate

Link to comment
Share on other sites

Quote:

natew said:

Hi Howard,

 

Do you get a blue screen any time you run Retrospect after running InCD? Please test this.

 

The fact that you have made extra copies of the catalog files on the CDRW should make no difference in Retrospect. If you do not use your CDRW drive as a backup device it is a good Idea to ignore it in the Retrospect environment window.

 

Are you actively using the catalog files stored on your CDRW drive?

Nate

 


 

The problem has occurred each of the 3 times I have run REtrospect, after copying files tp the CD-RW and not rebooting before I run Retrospect.

 

My system has 10 logical drives.

 

C-D, F-M

 

OS is on G.

 

Problem appears tp occur at a point when Retrospect would be trying to update the catalog.

Catalog is on I drive.

 

I suspect that InCD still has it's hooks on the files on the I drive, or is preventing Retrospect from configuring the CD-RW drive.

 

However, the CD-RW drive is not involved once I start running th Retrospect script, so that seems like an odd conflict.

 

I am not actively using the catalogs on the CD-RW.

They are there just for backup and the CD-RW media is not present when Retrospect is running.

Link to comment
Share on other sites

Quote:

natew said:

Hi Howard

 

This is really strange.

Does ejecting the CDRW with the copied catalog files before the backup starts make a difference?

 

Was there any difference when you told Retrospect to ignore the CDRW drive?

 

Thanks

Nate

 

 


 

I already stated that the CD-RW is removed before running Retrospect, so the problem is either drive contention or IncD/Windows may have not released the file handles used to copy the catalog/config file to the CD-RW. Both of those problems would be cured by a reboot, so that would be a reasonable explanation of the cause of the problem.

 

Before I fret about this further, I am going thru my previous posts to see what other questions remain unanswered.

 

Link to comment
Share on other sites

Quote:

Howard Kaikow said:

Quote:

natew said:

Hi Howard

 

This is really strange.

Does ejecting the CDRW with the copied catalog files before the backup starts make a difference?

 

Was there any difference when you told Retrospect to ignore the CDRW drive?

 

Thanks

Nate

 

 


 

I already stated that the CD-RW is removed before running Retrospect, so the problem is either drive contention or IncD/Windows may have not released the file handles used to copy the catalog/config file to the CD-RW. Both of those problems would be cured by a reboot, so that would be a reasonable explanation of the cause of the problem.

 

Before I fret about this further, I am going thru my previous posts to see what other questions remain unanswered.

 

 


 

I did a further experiment which might support my theory that the problem might be caused by InCD still somehow holding on to the file handle of the Retrospect catalog file.

 

1. If I copy the Retrospect catalog files to the CD-RW, the problem I descrbe in this thread occurs unless I reboot the system before running Retrospect.

 

2. However, if I copy some other file to the CD-RW, then run retrospect no such problem occurs.

 

This is consistent with the following:

 

1. InCD would need to have opened the file for read access, as would Retrospect when the time came to backup the file.

 

2. InCD would also have needed to open the Retrospect catalog file for reading when I copied the file to the CD-RW, however, Retrospect would also be trying to write to the catalog. I would guess that somehow Retrospect is being prevented from writing to the catalog file.

 

Note this type of file handle, or OLE, problem is unfortunately not uncommon.

 

I periodically have to account for a file handle not being properly released by Word/Excel, or interference from Norton Auntie Virus' Office plug-in (which nearly everyone should dusable as it is not needed if you have NAV's AutoProtect enabled) and, see the discussion of a PDFmaker problem by clicking on this link.

Link to comment
Share on other sites

Hi

 

Sounds reasonable to me. I wonder if Windows XP`s shadow copy API would work around this problem? That could be why we don't hear more about it.

 

As a workaround, you could script Retrospect to duplicate your catalog files to another location on the hard disk. Then you can copy the duplicated catalogs to your CDRW.

 

Seeing as we can't fix InCD it may be the best solution.

 

Nate

Link to comment
Share on other sites

Quote:

natew said:

Hi

 

Sounds reasonable to me. I wonder if Windows XP`s shadow copy API would work around this problem? That could be why we don't hear more about it.

 

As a workaround, you could script Retrospect to duplicate your catalog files to another location on the hard disk. Then you can copy the duplicated catalogs to your CDRW.

 

Seeing as we can't fix InCD it may be the best solution.

 

Nate

 


 

Windows XP is irrelevant.

 

I am using Windows 2000.

 

 

Retrospect is irrelevant to how I duplicate the catalog.

Indeed, when copying a file associated with an app, it just has to be safer to have the app not running during the copy.

I'd never use Retrospect for an ordinary file copy.

The workaround suggested above might not avoid the problem as InCD still has its fingers on the CD-RW media and files.

 

Only sure solution is a reboot.

 

In any case, this type of problem MIGHT be prevented if Dantz developers were made aware of the problem and added some error checking prior to writing to the catalog the first time in a Retrospect session.

 

Link to comment
Share on other sites

Howard,

 

My point was that Retrospect can use the open file backup functionality that is built into windows XP. As a result, Retrospect can still access the catalogs even though InCD is using the file. As many people use windows XP that could explain why we don't hear more about this.

 

 

 

Link to comment
Share on other sites

Quote:

natew said:

Howard,

 

My point was that Retrospect can use the open file backup functionality that is built into windows XP. As a result, Retrospect can still access the catalogs even though InCD is using the file. As many people use windows XP that could explain why we don't hear more about this.

 

 

 

 


 

Windows xP is irrelevant, my problem occurs on Win 2000.

Also, the version of InCD might matter. I'm ussing version 3.5.24.0 because InCD $.* has had two severe bugs that concerned me, one of which has been fixed. When the other main InCD bug of interest is fixed, I'll switch to InCD 4.* and see if the problem continues.

 

Several weeks ago, Ahead stated they had a fix for the bug, but they have not released an update to InCD since 8 September 2003. Usually, there's an update about once per month.

Link to comment
Share on other sites

Quote:

Howard Kaikow said:

Quote:

natew said:

Howard,

 

My point was that Retrospect can use the open file backup functionality that is built into windows XP. As a result, Retrospect can still access the catalogs even though InCD is using the file. As many people use windows XP that could explain why we don't hear more about this.

 

 

 

 


 

Windows xP is irrelevant, my problem occurs on Win 2000.

Also, the version of InCD might matter. I'm ussing version 3.5.24.0 because InCD $.* has had two severe bugs that concerned me, one of which has been fixed. When the other main InCD bug of interest is fixed, I'll switch to InCD 4.* and see if the problem continues.

 

Several weeks ago, Ahead stated they had a fix for the bug, but they have not released an update to InCD since 8 September 2003. Usually, there's an update about once per month.

 


 

Ahead released InCD 4.0.7.2 on 28 Oct 2003.

 

Appears to fix the Word bug, but I have not yet tried to see whether 4.0.7.2 corrects the problem I mentioned at the start of this thread.

 

However, there is something new.

InCD apprarently now updating a file named SrvError.Log, so that file shows up as an error when running Retrospect. Do not believe the error matters.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...