My backup fails to run with the error “The process cannot access the file because it is being used by another process.” It doesn’t tell me what the file is. I only have user area folders selected for backup, no application folders, I have system, hidden and temp files excluded, and it’s running a couple minutes after boot and I haven’t started running anything myself. The weird thing is that sometimes it is able to run. If I knew what file it was failing to access, then I could solve the problem of why it can’t access it.
Welcome to the forum @Gunslinger
The detailed error message would probably say more, but details get lost in the simple summaries.
Try looking at About → Show log → Live → Warning. If you see the message, try clicking to expand.
So, the detailed message in the log is:
System.IO.IOException: The process cannot access the file because it is being used by another process.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.InternalMove(String sourceFileName, String destFileName, Boolean checkHost)
at Duplicati.Library.Main.Operation.RepairHandler.Run(IFilter filter)
at Duplicati.Library.Main.Operation.BackupHandler.PreBackupVerify(BackendManager backend, String protectedfile)
at Duplicati.Library.Main.Operation.BackupHandler.d__20.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at CoCoL.ChannelExtensions.WaitForTaskOrThrow(Task task)
at Duplicati.Library.Main.Controller.<>c__DisplayClass14_0.b__0(BackupResults result)
at Duplicati.Library.Main.Controller.RunAction[T](T result, String& paths, IFilter& filter, Action`1 method)
at Duplicati.Library.Main.Controller.Backup(String inputsources, IFilter filter)
at Duplicati.Server.Runner.Run(IRunnerData data, Boolean fromQueue)
To me, this shows bad programming, as there should be a check before the python just crashes so that you can get meaningful information.
“To me, this shows bad programming, as there should be a check before the python just crashes so that you can get meaningful information.”
I’m actually going to back Duplicati devs on that one lol. Its technically still in beta because of the shape its in. That said, there’s areas where it was never hardened and things were missed typical of a beta since it requires polish and hardening generally heavily done for production release. I’ve already found some areas that have bad problems the code doesn’t deal with that’s been going for some years. I just don’t like answers where its not Duplicati at fault when it definitely can be.
But, I’m not sure how the PreBackupVerify() is related to this. Looks like it might be with the remote files.
If this is in the verification part after the backup runs then I would think its remote file related as the local files should be done at that point. However, the remote backups by default run at the same time during the local file crawl to save time so even then it could be happening during the local file crawl.
Also, a quick look, the RepairHandler() can throw IOException which is also in PreBackupVerify() as a remote error: catch (RemoteListVerificationException ex) {...new RepairHandler()...} as eg EXAMPLE "Found {0} remote files that are not recorded in local storage, please run repair" ... throw new RemoteListVerificationException(s, "ExtraRemoteFiles");
Maybe that will help you work past it. Probably have to dig into this deeper to see what the actual issue is. But, if there’s a remote access problem not the fault of Duplicati then Duplicati can’t actually do anything anyway and its not Duplicati in that instance. Could be it, but I’ve seen instances in my own development where its not the application.
If this is related to local files, I’m not seeing it. Could be I’m missing that but the code involved seem to be suggesting remote files.
Could also be another issue is actually involved that Duplicati should be dealing with. But, like I said, it has to be looked into deeper.
Looking at this a bit further, I believe it should be capable to get more logs for it and understand it better as there should be logs not posted as of yet. They could be in the backup info section or might need logging verbosity increased (please note the increase can result in personal and sensitive info so do not post that).
I probably won’t look at this further unless I see something that catches my interest.
Do you have auto-cleanup set in Advanced options? If so, turn it off, and Repair manually as needed.
If this is it, it’s only been a few weeks that it’s been understood well enough to have reproducible steps.
Since you mention Python (which this is not – it’s C#), if you’re a developer, read the latest theory here.
I do not have any advanced options set. I do have a custom retention set to “1W:1D,4W:1W,3M:1M”. I’m storing the backups on a server drive mounted as a drive letter. It’s auto-mounted and I don’t start a backup until 10 minutes after I power on, if I haven’t just left the computer on all night.
So I suppose this is the Destination side. Is the Source side from a local drive that’s always there?
Does that mean it’s a manually initiated backup? Has it ever worked? If not, have you tried a variation?
is a pretty clear statement that it never got going. You can probably cause a similar verification manually using the Verify files button for the job. Also look in job’s Show log → Remote to see if it has a list. Ordinarily you can click on this to see what files were seen at the destination. I’m not sure yours worked.
leaves me wondering how it went into Repair, seen on stack below:
The code above shows how auto-cleanup plus a verification exception gives a warning then tries Repair.
You can read the Commandline screen to be sure auto-cleanup didn’t get in another way (e.g. Settings).
You can also try watching About → Show log → Live → Information to see the path leading up to the fail.
Yes, the source side is my local drive. It’s not a manual backup, it’s an automatic, every work day at 7a. It does work some of the time. I had thought the difference was that it worked when I left my computer on over night, but that wasn’t always true.
The log for the job only has entries for the days it worked. The verification didn’t give any errors and I did it just after the actual backup had failed.
Apparently the auto-cleanup is set in the command line, even though it doesn’t show it when looking through the wizard.
There’s a merge with Settings default options. Are you certain there’s nothing at below screen for you?
The merge is also done if you Export As Command-line, except it will be a text string for use on true CLI.
You’re probably talking about <job> → Show log → General. What about <job> → Show log → Remote?
So, I did an experiment. Now that the option is not enabled, I ran through the Edit wizard and added it. Then when I run through the wizard again, I see it checked. So I unchecked it and saved it. Then I ran through the wizard again, and the option was still listed but unchecked. However, there is a checkbox on the far right as well, which I believe removes the option from the screen, but it probably doesn’t change the value of it in the settings. So, I probably enabled it at some point and then clicked that box so it disappeared from the GUI listing, but it was still enabled in the settings. I would call that a bug that should be fixed in some way (there’s several options).
Both the remote and local log had no entries when it failed, other than the failure message.
It does here, after I delete the checked option, save, view Commandline.
Can you reproduce a problem? I don’t recall anyone claiming this before.
Please let us know how the backup is doing.