Backup Error 5: Access is denied - Reinstall did not help

Thanks for sending your config. (Not sure why all the archives were self-extracting .exe files so I think some of the instructions still got confused somewhere, but I have the config now anyway).

I haven't isolated the exact cause yet but my guess is that the problem is you are treating Opus's config directories as a place to store a lot of your own random files as well as shortcuts to various other folders.

When I get a chance I'll work out exactly which files are causing the problem, but my advice so far is to stop messing with the config directories (that includes customizing their icons, which will create hidden files below the customised folder) and storing random things inside them. Opus expects the config dirs to contain certain things arranged in a specific way and they aren't a general user documents folder.

It's because the function Copy ADDTOARCHIVE HERE is greyed out unless I chose one of the compression option (Archive type) or only if I choose the option "Make self-extracting archive":

Thus, this is the reason why the first time you asked for the zipped files, I wrote to you that I used the options to zip with 7z, rar and zipx. Until you confirmed that the function Copy ADDTOARCHIVE is the one to use and I noticed and chose the self-extracting archive option, I was able to create the files you asked for. Therefore, you see, I didn't have any other options left because the remaining options can't clear out the greyed-out OK allowing me to do the zipping.

I cleared all attributes of all directories and files in all three locations and deleted all shortcuts and desktop.ini files. The backup is still locked at error 5.

It's probably a gender thing because I like to pretty-up my directories and it helps me find them with just a glance.

At the risk of repeating myself, the backup function worked until 10.5.06 BETA despite all the things that aren't supposed to be in my Opus config directories and my configuration hasn't changed for a very long time. I don't understand why functions start to break-up for me since 10.5. There are many things going on under the hood that I most certainly don't understand but the improvements have a knack to mess up with my working Dopus.

Another point is that I remember that backups started to get slower with 10.5.0, especially towards the end of the process around the ninetieth percent, but still completed successfully. I hope this additional piece of information will help you and Jon narrow down the culprit.

Ah okay, that makes sense. You've turned off Preferences / Zip & Other Archives / Zip Files / Enable internal Opus Zip support so almost all of the zip functionality in Opus is disabled.

I cleared all attributes of all directories and files in all three locations and deleted all shortcuts and desktop.ini files. The backup is still locked at error 5.[/quote]

The problem is in the Icons directory.

The files selected in the screenshot below are the ones you need to delete. (Note that the screenshot scrolls down.)

Essentially, delete everything except for the 18 .ico files (near the bottom) and the .dis file (near the top).


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.

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.

Basically, use Opus's Preferences and Customize user interfaces to make config changes rather than going into the config directories and changing things by hand. Don't spent time in the config directories or use them to store shortcuts to other places or make them look pretty; you should be looking at those directories as little as possible (almost never; it's almost never needed). Let Opus manage its own config dirs.

The only thing you might need to manually copy into the config directories is individual Icons, Images and Sounds. (And the special Scripts folder if you use that for USB Export.)

If there are parts of the configuration which you've been manually editing and you don't know where the user interface for them is, just ask and we'll help. That sort of question is usually really easy to answer so you'll get a reply very quickly, as long as one of us is awake. :slight_smile:

Not much changed between 10.5.0.6-beta and 10.5.1.0. (The four changes are listed here. If we made significant changes after 10.5.0.6-beta then we would have released another beta before 10.5.1.0.)

I've checked and the problem occurs with 10.5.0.6 as well, so you probably just hadn't triggered it yet.

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.

I'm still looking into exactly what is going wrong with those unicode characters, and if there's a bug somewhere we will fix it, but we will still never support or guarantee that Opus will work if you put random files into its config directories. Put that stuff somewhere else and use the UI to make config changes. Only manually go to or modify the configuration directories as a last resort.

Probably because of all the stuff in your config dir. :slight_smile: It looks duplicate copies of several config directories have been made by mistake, accumulating a mess of files that will increase the backup time. The copies of the Images and User Commands files into the Icons directory may have been from an accidental drag & drop. Avoiding that kind of accident is another reason to avoid making manual changes to the config directories.

Hi Leo,

Thanks for looking at my trouble. I'm writing a short reply to let you know I'll look into your suggestions for remedial and get back to you in a few days because I'm swamped right now.

Hi Leo,

Spring has finally come to Denmark — and with spring comes gardening. That's why I've not been at my computer for the last two days. However, seeing that you are focusing on the point <copying from your post Tue Apr 16, 2013 10:50 am > :

"I haven't isolated the exact cause yet but my guess is that the problem is you are treating Opus's config directories as a place to store a lot of your own random files as well as shortcuts to various other folders."

. . . I just want to add to my earlier post (Tue Apr 16, 2013 6:28 am ), that I has not been doing any dabbling with Dopus's files or folders — and I have the (exact ?) same problem.

And I still find it weird that Dopus cannot see the files it has created itself in the ...\Temp.... .dop\ folder (as shown in the attached Process Monitor log to my earlier posting).

Another thing — I noticed that chooquette wrote in post Tue Apr 16, 2013 3:34 pm (copy) :

"Another point is that I remember that backups started to get slower with 10.5.0, especially towards the end of the process around the ninetieth percent, . . . "

As I wrote in my earlier post, my backup stops with the error message "Access is denied" when the progress bar has progressed to about one tenth from its final end. Is that just a coincidence, or ???

I know, these are only some very small bits — but I thought, better to post them than not to . . .

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. :thumbsup: Leo.

@belion: I'm curious if your trouble with backing up is similar to mine. Please keep us updated if you can :slight_smile:

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 :slight_smile: