Jump to content

NTFS errors


kaikow

Recommended Posts

Yesterday, I converted 9 of the 10 logical drives on my 3 hard drives to NTFS.

 

 

 

Then I did a Recyle backup.

 

 

 

An error occurred during the COMPARE phase for each of the NTFS drives. The following was for the M drive:

 

 

 

File "M:\System Volume Information\tracking.log": different modify date/time (set: 2/19/2006 19:34:17, vol: 2/20/2006 04:42:31)

 

2/20/2006 04:52:37: 1 execution errors

 

 

 

In this case, Retrospect is installed in the Win 2000 on the J drive, and the catalog is on the I drive. Perhaps, this explains the error for the I and J drives (but no such error occured when the drives were FAT 32),

 

 

 

No programs were running that would not also have been running when the drive was FAT 32.

 

And, I was asleep, so my fat fingers could not have been running anything.

 

 

 

Is this normal behavior due to the way NTFS works?

Link to comment
Share on other sites

The problem appears to have been caused by NTFS changing the tracking.log file because the Distributed Link Tracking Client service was set to Automatic.

 

Changed the service to Manual and the problem went away.

 

Guess if I ever need the service, I'll find out the hard way.

Link to comment
Share on other sites

I do not know if this is related to the problem I posted in this thread.

 

Recently, I started getting the errors listed below

I do not recall ever previously getting a Copying error.

The Compare errors are not significant.

System is Win 2000.

 

The only significant changes made since converting the drives to NTFS were:

 

1. Installing Diskeeper Lite version 7: This does work in the background, soI have uninstalled th software to see whether ii might have caused the error messages. Still got the messeages.

 

2. Installed Ghost 10: I've had Ghos 10 installed before with no unexplainable REtrospect errors. I have uninstalled Ghost 10, but still get th emessages.

 

3. As suggested earlier in this thread, I set the Distributed Link Tracking Client service to Manual and Stopped the service. I have now restored the old settings of Automatic and Started, but still get the messages below. Note that I am not getting the tracking.log messages.

 

What causes the messages below?

 

In the interim, I guess I have to switch to Ghost as that has no problems with open files.

 

 

- 2/26/2006 08:32:05: Copying MICRONJ (J:)

File "J:\Documents and Settings\Howard Kaikow\NTUser.Dat": can't read, error -1020 (sharing violation)

File "J:\Documents and Settings\Howard Kaikow\ntuser.dat.LOG": can't read, error -1020 (sharing violation)

File "J:\Documents and Settings\Howard Kaikow\Local Settings\Application Data\Microsoft\Windows\UsrClass.Dat": can't read, error -1020 (sharing violation)

File "J:\Documents and Settings\Howard Kaikow\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat.LOG": can't read, error -1020 (sharing violation)

File "J:\Program Files\Common Files\Symantec Shared\CCPD-LC\symlcrst.dll": can't read, error -1020 (sharing violation)

File "J:\Program Files\Common Files\Symantec Shared\CCPD-LC\symlcsys.dll": can't read, error -1020 (sharing violation)

File "J:\Winnt\system32\Perflib_Perfdata_594.dat": can't read, error -1020 (sharing violation)

File "J:\Winnt\system32\config\DEFAULT": can't read, error -1020 (sharing violation)

File "J:\Winnt\system32\config\DEFAULT.LOG": can't read, error -1020 (sharing violation)

File "J:\Winnt\system32\config\SAM": can't read, error -1020 (sharing violation)

File "J:\Winnt\system32\config\SAM.LOG": can't read, error -1020 (sharing violation)

File "J:\Winnt\system32\config\SECURITY": can't read, error -1020 (sharing violation)

File "J:\Winnt\system32\config\SECURITY.LOG": can't read, error -1020 (sharing violation)

File "J:\Winnt\system32\config\SOFTWARE": can't read, error -1020 (sharing violation)

File "J:\Winnt\system32\config\SOFTWARE.LOG": can't read, error -1020 (sharing violation)

File "J:\Winnt\system32\config\SYSTEM": can't read, error -1020 (sharing violation)

File "J:\Winnt\system32\config\SYSTEM.ALT": can't read, error -1020 (sharing violation)

2/26/2006 08:37:23: Snapshot stored, 53.5 MB

2/26/2006 08:37:30: Comparing MICRONJ (J:)

File "J:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate\2006-02-26_Log.ALUSchedulerSvc.LiveUpdate": different data size (set: 1,844, vol: 2,305)

File "J:\Program Files\EPSON\EPSON SMART PANEL for Scanner\SmaPanel.ini": different modify date/time (set: 2/26/2006 08:33:12, vol: 2/26/2006 08:37:34)

File "J:\Winnt\setupapi.log": different modify date/time (set: 2/26/2006 07:59:28, vol: 2/26/2006 08:37:15)

2/26/2006 08:37:45: 20 execution errors

Link to comment
Share on other sites

I have been using Retrospect since June 2003, and have never purchased the Open Fiole Backup option, nor ever had a problem Copying before.

 

So, this must have something to do with reformatting the drives as NTFS, or with my changing the settings for the Distributed Link Tracking Client.

 

I'll try uninstalling, then re-installing, Retrospect.

Link to comment
Share on other sites

Quote:

I have been using Retrospect since June 2003, and have never purchased the Open Fiole Backup option, nor ever had a problem Copying before.

 

So, this must have something to do with reformatting the drives as NTFS, or with my changing the settings for the Distributed Link Tracking Client.

 

I'll try uninstalling, then re-installing, Retrospect.

 


 

Uninstalling, then re-installing, did not correct the problem.

The implication is that moving from FAt 32 to NTFS AND changing the Distributed Link Client service to Manual broke something in Retrospect.

 

Clearly, not being able to back up the System State is a show stopper.

 

Time to move on to another backup program until Dantz/EMC responds on how tp fix.

Link to comment
Share on other sites

Note that the system is multiboot.

 

When I got Retrospect in June 2003, main OS was on the G drive, and thar's

where I installed Rerospect.

 

When I installed a clean Win 2000 on the J drive, I uninstalled Retrospect

fromn the OS on the G drive, and installed Retrospect in the OS on the J

drive in Nov 2003.

 

Until I changed to NTFS, no problems.

 

So yesterday, I booted to the G drive and installed Retrospect there.

No unexpected copyingcompare prolems, tho it executed a lot more slowly than

Retrospect on the J drive.

 

Today, I uninstalled, then re-installed, Retrospect on the J drive.

Problem still exists.

 

Perhaps, Retrospect has a bug when file system is changed and Distributed Link Tracking is set to Manual.

 

Seems to prevent backup of System State.

Link to comment
Share on other sites

Hi Howard,

 

If you don't have the Open File Backup option, you are not going to be able to back up open files on a Windows 2000 machine. Judging from this Microsoft article (http://support.microsoft.com/kb/312403/) it seems Distributed Link Tracking (DLT) is designed for use on NTFS formatted volumes only, which would explain why you hadn't seen that initial compare error before. Also judging from this article, DLT is used to track linked file locations, I don't see any references to open files.

 

Your logs shows system state related files are not backing up directly, but have you checked the properties of the snapshot for your boot volume to see if the snapshot gathers system state info during the snapshot creation process?

 

Configure>Backup sets>Properties>Snapshots>Properties. You should see an option that says Contains: and lists several items such as regestry, WMI repository and other system state related items.

Link to comment
Share on other sites

The issue is more clearly stated as follows:

 

1. If I install Retrospect in the OS on the G drive, I do not get the errors that I get with Retrospect installed in the OS on the J drive. It's a multiboot system, so same drives are used by all the OS.

 

2. However, on the G drive, I never changed the Distributed Link Tracking Client service settings (and the tracking.log messages did not appear). The implication is that changing that setting in the OS on the J drive somehow made Retrospect unhappy with the settings and unable to back up the System State running Retrospect from the OS on the J drive.

 

3. Backing up the System State is a different issue than backing up open files. Retrospect has previously always backed up System State.

 

Of course, I could boot to the OS on the G drive and backup the J drive from there, but that's rather an inconvenient way to operate.

 

I'm sure the folkes back in Retrospect development understand this issue.

 

Until I get a response that resolves the problem, I'll have to switch to Ghost 10 (which I do not like) and Acronis True Image 9 (ordered a few minutes ago).

Link to comment
Share on other sites

Hi Howard,

 

I assume these errors happen on the same files every time you run a backup?

Can you try this please?

 

Copy and paste one of the log files to another location on disk and run another backup. Does the copied file cause an error as well?

 

Thanks

Nate

Link to comment
Share on other sites

Hi Howard,

 

I tried this out on my XP sp1 machine. I disabled the Distributed Link Tracking Client service and ran a full backup. I had no open file errors (I am on XP) and I had no problems building a snapshot with system state information. This was with 7.0.326, I don't believe you've mentioned what version you're using in this thread.

 

So I would like to ask again, are you certain you are not getting the system state? You never verified that you checked the properties of your snapshot, so judging by the log you posted your only problem would appear to be open files.

Link to comment
Share on other sites

Quote:

Hi Howard,

 

I tried this out on my XP sp1 machine. I disabled the Distributed Link Tracking Client service and ran a full backup. I had no open file errors (I am on XP) and I had no problems building a snapshot with system state information. This was with 7.0.326, I don't believe you've mentioned what version you're using in this thread.

 

So I would like to ask again, are you certain you are not getting the system state? You never verified that you checked the properties of your snapshot, so judging by the log you posted your only problem would appear to be open files.

 


 

As I statedbefore, the system is multiboot (all OS are Win 2000, with same level of Windoze updates).

 

Problem occurs only with the REtrospect installed when booted to the main OS (on the J drive), which is where the DLTC service settings were flipped.

 

No problem running Retrospect installed when booted to the OS on the G drive, where DLTC settings were not changed.

 

NEVER had any unexpected problems with COPY before.

 

So whatever code Retrospect uses to backup the system state works in the OS on G, but not the OS on J.

 

I'd guess that if I also installed Retrospect in the OS on C and the OS on F, there would not be a problem.

 

The implication is that changing the DLTC service settings somehow broke Retrospect's ability to deal with the System State files, which are always open. Makes no sense, but that's the only evidence we have.

 

Version of Retrospect is 6.5.350, which I've used since April 2004.

Link to comment
Share on other sites

Hi Howard,

 

I tried the backup again, matching your setup a little more closely. Using Retrospect Professional 6.5.350, RDU 5.4.110 I ran a backup to a disk backup set of the entire C: drive while the Distributed Link Tracking Client service was disabled. I did not recieve any errors in my operations log regarding system state or snapshot creation. Upon checking the properties for my snapshot I could see that the system state had indeed been backed up correctly.

Link to comment
Share on other sites

Quote:

Hi Howard,

 

I tried the backup again, matching your setup a little more closely. Using Retrospect Professional 6.5.350, RDU 5.4.110 I ran a backup to a disk backup set of the entire C: drive while the Distributed Link Tracking Client service was disabled. I did not recieve any errors in my operations log regarding system state or snapshot creation. Upon checking the properties for my snapshot I could see that the system state had indeed been backed up correctly.

 


 

There is no point in trying to replicate my problem.

 

Retrospect works properly in the OS on the G drive, but does not wirk properly in th OS on the J drive on the same system.

 

Implication is that some setting got changed when flipping the DTCL service option,and this is somehow messing up Retrospect.

 

I likely could build a clean Win 2000 on the L drive, and re-install everything, but that's way too time consuming.

 

For daily use, I'll just have to switch to Ghost 10 and True Image 9(arriving tomorrow). Periodically, I might boot to th G drive to use Retrospect, but that's a bit inconvenient.

Link to comment
Share on other sites

Quote:

Hi Howard,

 

Did you try turning the DTLC service back on to see if the problem went away?

 


 

Yes.

 

Quote:

only difference between the G drive and the J drive, right?

 


 

No, but that's not the issue.

X daze ago, Retrospect worked on the J drive, then it started having problems.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...