Open File Backup error (-1017 insufficient permissions)

[awnews]

I just upgraded an XP SP1 PC from RP 6.5.343 to .350, RDU 4.9.101 and rebooted. I'm now seeing errors, in multiple scripts, of "-1017 (insufficient permissions)" regarding Open File Backup when backing up files from a second IDE drive (V: drive; OS + RP are on the main C: IDE drive) to a third IDE drive (W:) on the same machine. The logged in user matches the Prefs=>Security user (name, password, domain) in Retrospect. This user is admin-level and had full control of all drives & directories on this PC. Despite the error, it does seem to back up expected data (just without OFB?). This wasn't seeing this error until I upgraded to .350 (logs going back for months show 0 entries for these and other scripts).

 

+ Duplicate using CadenceLibs_Monday at 5/11/2004 3:31 AM

Can't use Open File Backup option for CadencePSD14libs on Drive V (V:), error -1017 (insufficient permissions)

To volume Monday on Drive W (W:)...

 

- 5/11/2004 3:31:34 AM: Copying CadencePSD14libs on Drive V (V:)

5/11/2004 5:11:22 AM: Comparing Monday on Drive W (W:)

5/11/2004 5:13:52 AM: 1 execution errors

Completed: 176 files, 2,548 KB

Performance: 0.1 MB/minute (0.1 copy, 0.9 compare)

Duration: 01:39:54 (01:10:00 idle/loading/preparing)

[natew]

Hmmmmmm

 

This is odd. Retrospect should be using the built in XP shadow copy API to backup files on this machine. I'm also not sure why it would happen on only one drive. As a test can you try clean preferece filess? The drive is NTFS right?

 

Thanks

Nate

[awnews]

The messages stopped a couple of days ago (post "a couple of reboots"). They were showing up in the logs & in the Events pane. At the moment I'm no longer getting the OFB messages (with "0 errors"). And yes, all volumes on all of my PCs are NTFS.

 

I was surprised at the suggestion to delete/replace the prefs file. This is *not* "free" in that it would require a user to restore settings, scripts, etc. Perhaps, given the frequency at which "replace the prefs file" is suggested, Dantz should come up with a way to validate the sanity of the prefs files (built-in checks [content, CRC, etc.], separate utility to parse the prefs file, etc.

[natew]

Hi GoAWest,

 

I only offer removing preference files as a test soltion to help narrow down the problem. I realize it requires a lot of time recreating them. In the event we narrow down the problem to corrupt configs you can restore an older version from backup.

 

Thanks

Nate

[awnews]

But I think it's a fair question to ask "what is causing this mythical prefs file corruption" (that may or many not exist)? Perhaps the right answer would be for Retrospect to include features & procedures to make sure it *never* corrupts the files itself. And, if the concern is that other "things" (other programs, the OS, disk problems, etc.) are corrupting the prefs file, provide checks (e.g. syntax checks, range checks, checksum/CRCs over sections or the entire file). *Prevent*, *fix* and/or *diagnose* pref files problems and we won't have to wildly speculate on "maybe the prefs file is corrupted" or "maybe it's alpha particles or sunspots" or ...

[natew]

Hi

 

There is some degree of CRC / error checking to determine if the config file is valid or not. There is also a backup of the file with the "last known good" configuration if needed. Not quite all you are hoping for though...

 

Like a reboot, starting with clean prefs is basic Retrospect troubleshooting. It gives us a clean slate to try to figure out if the problem is in Retrospect or elsewhere on the machine.

 

If any file in Retrospect is going to get fouled up that is the one. Its pretty much the only writeable Retrospect file. Most of the time it isn't corrupt but it is a good place to start lloking for problems - especially when strange errors (like the 1017 error you had) show up.

 

Thanks

Nate