Cannot Access File

[Ragonz]

• I have searched open and closed issues for duplicates.

---

Environment info

• Duplicati version: 2.0.4.5_beta_2018-11-28 (also tried on canary 2.0.4.10)
• Operating system: Windows Server 2012R2
• Backend: Google Drive

Description

Every so often Duplicati will throw a "The process cannot access the file because it is being used by another process, no other duplicati process is running as far as I can see and I can freely move the data folder and its contents about if I stop duplicati. This is not an isolated incident and is occuring on 10+ servers randomly. The only way to fix this I have found is to delete the local database and remote files (or rename the remote folder) and essentially start again.

Steps to reproduce

1. Install duplicati as a service, see instructions below
2. wait

Install as a service instructions

1. Download zip copy of Duplicati and extract to C:\Program Files\Duplicati 2
2. Run this command as administrator in command prompt
   "C:\Program Files\Duplicati 2\Duplicati.WindowsService.exe" install --portable-mode --webservice-interface=loopback --log-retention=3M
3. Start the service
4. Configure the backups

• Actual result:
  Backups should run without issue
• Expected result:
  Duplicati occasionally errors suggesting a file is in use (I suspect one of the database files) once the error occurs it will continue to occur until you delete the local database and remote files and start fresh.

Screenshots

Debug log

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.<RunAsync>d__19.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__DisplayClass13_0.<Backup>b__0(BackupResults result) at Duplicati.Library.Main.Controller.RunAction[T](T result, String[]& paths, IFilter& filter, Action1 method)
at Duplicati.Library.Main.Controller.Backup(String[] inputsources, IFilter filter)
at Duplicati.Server.Runner.Run(IRunnerData data, Boolean fromQueue)`

[warwickmm]

Is the path containing the Duplicati local database files included in the sources being backed up? That can often lead to issues similar to this one.

[ts678]

I don't think this is well-understood, but the most useful thread I saw was in the forum, with a workaround.

2.0.4.5 - The process cannot access the file because it is being used by another process

I'm guessing the point of fail is here, where repair tries to rename the database. There's an Information-level message right above it, if you want to set up a --log-file at --log-file-log-level=information to see how often the rename runs, and how often it fails. I'm not familiar enough with it to say much about what's happening.

[DesktopMasters]

This problem is not resolved. I see posts about the bug going back as far as 2015. I would love it if it could get more attention.

I have Duplicati running on at least 30 computers. This problem has been continuously showing up on the computers regularly. I can confirm that “–concurrency-max-threads=1” does not stop it from happening. This bug really ruins the program for me.

[drwtsn32x]

@DesktopMasters are you running Duplicati the same way the OP is?

I occasionally get the error about in-use files during backups, but it is a legitimate error. I use VSS but sometimes the snapshot fails so in-use files cannot be backed up.

[Ragonz]

I forgot about this thread but was emailed when people replied to it.
We still get this problem and no don't backup anything to do with duplicati itself.

The usual fix is stop all duplicati services, kill all duplicati process's start services, run repair carry on. but a fix so that it doesnt happen would be nice.

[drwtsn32x]

@Ragonz - what version are you running? I run Duplicati on about 10 machines and have not experienced the issue you describe. But I also don't run it in 'portable mode' - maybe that's a clue.

[DesktopMasters]

I am running Duplicati as a service and storing its data in the C:\ProgramData\Duplicati folder. I am NOT backing that folder up.
Backup is being stored in SFTP but I also have computers occasionally having this issue backing up to a local USB drive.
Computers are different Windows OS's. The one I just had the issue on was Windows 10 Pro.
I am running version 2.0.4.23_beta_2019-07-14

--snapshot-policy=Required
--auto-cleanup=true
--thread-priority=highest
--concurrency-max-threads=1
--rebuild-missing-dblock-files=true
--usn-policy=Auto
--retry-delay=60s

I just changed snapshot-policy from Auto to Required. I feel like maybe that could help. I will report back if it solves the problem.

[Ragonz]

Duplicati - 2.0.4.23_beta_2019-07-14

[drwtsn32x]

I just changed snapshot-policy from Auto to Required. I feel like maybe that could help. I will report back if it solves the problem.

All that's going to do is just fail the entire job if the snapshot cannot be taken. (I sometimes get that if another program is trying to create a snapshot at almost the same time.)

Auto may be better, at least you'll get most files backed up and just warnings about files that are locked.

[DesktopMasters]

Just to save you all the time... It did not solve it for me.
So this is stopping my backups from working till I go touch the computer to repair the database each time. Can we get an automation for this?

[drwtsn32x]

Can we get an automation for this?

That's not the right approach, IMO. We need to find out the root cause of why you are experiencing this issue. Something unique about your setup may be triggering it.

When the problem next happens, can you get a capture of the full log? I might also suggest removing most of your listed customizations except maybe --snapshot-policy=auto just to help try moving you back to a more vanilla config.

[ts678]

@Ragonz are you also running --auto-cleanup=true and if so, does turning it off change the problem, perhaps to something else? You can follow the same debugging steps including capturing a --log-file.

Using --log-file-log-level=information might be a good start, and tends not to catch personal info like profiling level can. Supply some context before the error too, as this will help show how it got to error.

What's needed is either enough log to show details on what happened, or getting closer to vanilla, as @drwtsn32x was suggesting, in order to find out whether some not-often-used option is responsible.

--auto-cleanup is my prime suspect based on your limited initial stack trace, because PreBackupVerify problems may have started a Repair run, which could not rename the database, because it was open...

duplicati/Duplicati/Library/Main/Operation/BackupHandler.cs

Lines 153 to 161 in 79d8395

	if (m_options.AutoCleanup)
	{
	Logging.Log.WriteWarningMessage(LOGTAG, "BackendVerifyFailedAttemptingCleanup", ex, "Backend verification failed, attempting automatic cleanup");
	m_result.RepairResults = new RepairResults(m_result);
	new RepairHandler(backend.BackendUrl, m_options, (RepairResults)m_result.RepairResults).Run();
	Logging.Log.WriteInformationMessage(LOGTAG, "BackendCleanupFinished", "Backend cleanup finished, retrying verification");
	FilelistProcessor.VerifyRemoteList(backend, m_options, m_database, m_result.BackendWriter);
	}

Repair doesn't look like it routinely renames the database, but it does if prior issues call for a Recreate.

duplicati/Duplicati/Library/Main/Operation/RepairHandler.cs

Lines 65 to 66 in 79d8395

	Logging.Log.WriteInformationMessage(LOGTAG, "RenamingDatabase", "Renaming existing db from {0} to {1}", m_options.Dbpath, baseName);
	System.IO.File.Move(m_options.Dbpath, baseName);