Please send me zips of your /dopusdata, /dopusglobaldata and /dopuslocaldata directories, and I'll see what's causing the problem in your config. I think I know what to look for now.
Hi Leo,
I finally got 5 minutes to myself and was able to solve my problem with your help. Thank you so much for your patience and benevolence to my woes and quirkiness.
I modified my setting for this feature to be able to do the zipping within Opus in case of future troubleshooting. I tend to disable all options that I feel I don't need in the programs I use.
[quote]The problem is in the Icons directory.
The problem is triggered by creating the ". Dopus Buttons [C:]"-style shortcuts with unusual unicode characters in them below the Icons folder, then doing a backup, then a restore, then another backup, and then another restore. If you then try another backup you'll get the error.[/quote]
Absolutely. The use of [:] to indicate the target drive caused all this havoc.
I understand.
[quote]It's the shortcuts like ". Dopus Buttons [C:]" with Unicode tricks to make them look like they have file paths which were causing the problem, but none of that extra stuff should be in the Icons config dir. (Shortcuts to various places, a directory full of user commands, copies of background images (that are also in the Images folder with different names), desktop.ini and icons used to customize the look of the config directories themselves, your Opus 9 and Opus 10 registration details...)
While it seems to only be these particular files in the Icons folder which were causing problems with the backup functionality, I suggest cleaning up the other config dirs as well, since many of them have similar things which shouldn't be there and may cause other problems now or in the future. Also the shortcuts, folder-icon customisations and ".------------" folders at the root of the config shouldn't be needed and may cause problems.[/quote]
Their use is gone in all Directory Opus directories on my system.
[quote]The Lan's Icon Set.dis file near the top should probably be moved up a level, in the Icons folder itself rather than the [bin] sub-folder, if you actually want to use those icons. Opus will completely ignore the .dis file when it's in a sub-folder like that, so it's just wasting space right now. But it's probably also harmless so you can keep it there if you wish.
You would normally import a .dis file into your config using Preferences / Toolbars / Icons, which automatically copies the .dis file to the appropriate place directly below the Icons folder.[/quote]
I don't know if you remember but you helped me create this .dis icon set. I didn't have the time to make the changes after that to point my icons to the new path on this .dis file instead of the .ico in my Icons directory. I hope to have some time soon to tackle this part in my configuration so that my USB configuration can resemble to the one on my hard drive. By the way, is there a way to do a find/replace in some .xml file to change these paths automatically?
It's just that most of the time, I don't even know that I need help when I start something. However, mostly, I don't to bother the help line for what I view as small matters. I pride myself to always try to troubleshoot for quite some time before deciding to post a request. I realize that most of the time, it'd have been quicker if I'd popped up a question to the forum instead of doing it by trial and errors. Nevertheless, thanks for the kind words and I'll keep your advice in mind for the next time I try to do something out of the ordinary.
Another problem solved. 
Leo.
@belion: I'm curious if your trouble with backing up is similar to mine. Please keep us updated if you can 
XML files can be edited in your favourite text editor, which should be able to do that.
[Off Topic] [quote="leo"][quote]By the way, is there a way to do a find/replace in some .xml file to change these paths automatically?[/quote]
XML files can be edited in your favourite text editor, which should be able to do that.[/quote]
I guess I worded my question poorly. What I meant is that if the current icon path in Buttons is:
%APPDATA%\GPSoftware\Directory Opus\Icons\xxx.ico,0
Therefore, how should the syntax be if I wish to change the aforementioned path to point to the one in the .dis file (all the icons in my .dis icon set have the same name as the one I use in my Icons' directory)?
Please start a new thread for that.
Just installed Opus Pro 10.5.1.0 for the first time ever on a WinXP SP3 just 2 days ago.
Tried to do only a "Misc + Local State" backup for the first time and it failed with "Error 5 - Access is denied (4)".
All I did was adjust some config settings in opus, never played with any of the advanced functionality of opus.
What gives?
The fix for what this thread is about was only released into 10.5.1.1 beta (and the subsequent 10.5.1.2 beta) so it won't be in the earlier 10.5.1.0 stable release.
If Leo's suggestion doesn't help then please download and run DebugView and then try the backup again - it should display debug output to indicate what is going wrong.
I have also been having this problem.
Reading everything here I went hunting and found the cause of my problem. Yes, a dodgy named file.
C:\ProgramData\GPSoftware\Directory Opus\Layouts\System\default.oll~RF4cc461d.TMP
Obviously some temp file that Dopus created. It is dated many months ago. I haven't backed up my config since then but haven't got around to sorting it out until now.
For anyone who wants to look for a similar cause: I stopped Dopus. Using Explorer I renamed "C:\ProgramData\GPSoftware\Directory Opus" to "xDirectory Opus". Started Dopus, tried backup, went ok. I then renamed "xDirectory Opus" back to "Directory Opus" and repeated the exercise for each subdir until I discovered the culprit. It was pretty obvious which file was the culprit from there.
Regarding some other suggestions above, which I tried. I got the error always at the same place, for me, about halfway through the backup. I could untick all options, change the filenamed and dir to save to, still got the error. I could use Dopus's zip to zip "Directory Opus" no problem. The Process Monitor log had a whole lot in it. I struggled to isolate anything there.
It would seem a good idea for Dopus developers perhaps to add a quick check before backing up to isolate any unacceptable file names.
Thanks all
As an aside. There must be a bit more to backup (or restore) than simply zipping "C:\ProgramData\GPSoftware\Directory Opus". While testing Dopus applied defaults for dirs I had renamed, which made a mess of my setup. When I had finished I restored the entire dir from last nights backup. My toolbars etc were all available but the window, toolbar, menu layouts were not as I had set them. I sorted it out so no problem but it was a pain so I wouldn't like to rely on that method.
More info. I thought I'd have a look at the DebugView log when the error occurred, so I created a file with same dodgy name in that dir. Backup did NOT fail. So I restored the dodgy file, backup DID fail. I noticed the dodgy file was 0 bytes so I created a 0 byte txt file. Backup did NOT fail. Not sure what to make of that.
However, I did capture the DebugView log entry when it failed with the dodgy file in place.
[4916] [7556] dopus: CfgBackup: Error 5, Failed to create K:\UserData\Temp\dtemp-ed7f858287613411-20.dop\Layouts\System\default.oll~RF4cc461d.TMP
I've tried creating a file called default.oll~RF4cc461d.TMP under both /dopusdata and /dopusglobaldata Layouts\System, but the backup still always works for me.
I wonder if there's a bit more to it, like the file had been locked in use by something as Opus was trying to create and rename it (which may also explain why it was still there in the first place). Maybe a virus scanner or system indexing service (which has been known to have issues with some XML data in the past, so isn't impossible).
If you create a new file with that name, does the backup start to fail again for you?
As I said in my previous post "so I created a file with same dodgy name in that dir. Backup did NOT fail. So I restored the dodgy file, backup DID fail. I noticed the dodgy file was 0 bytes so I created a 0 byte txt file. Backup did NOT fail. Not sure what to make of that."
I know it doesn't make sense but that's what happened. The file couldn't have been held in use either as I could delete it no problem.
It makes me think somehow it is not just the name but that particular file. But given it was 0 bytes, how can it have any effect other than its name?????
Unfortunately that file is no longer available so I can't test with it further, or upload it.
We've got a fix coming for the "default.oll~RF4cc461d.TMP" issue, after a second report where we got to see the config folder and were able to reproduce the problem.
In the end it was not the filename but the Hidden attribute on the file which caused the problem, due to Windows filesystem semantics when trying to overwrite Hidden files.
Excellent. Always nice to know I'm not going mad 