Just did a clean install of 2.0.2.9. Backup reports back after verifying backend data
The process cannot access the file because it is being used by another process.
Log shows:
Fatal error
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.Run(String[] sources, IFilter filter)
I am thinking that the database is in use (maybe by another Duplicati instance? Maybe by the same instance?) and this prevents the database from being updated?
That is the command to set the service up. After that I just do the “sc start duplicati”. I also double check the service to make sure it indeed did start and that it is set to automatic in the control panel services section.
It is something to do with fixing a problem, and for that it wants to write a new database, but the old database is locked. I think I know now what causes this problem, but I do not have an easy fix.
The backup is keeping a connection to the database open, but the repair process wants to replace the database with another version. When attempting to move the database file while a connection is open, you get this error.
The fix requires a change to how the backup process is using the database, which would allow this in-place update. I am working on that (among other things) in the concurrent_processing branch.
Deleting the database or deleting the whole job and recreating it doesn’t help so far. It seems I need to delete all backup files, haven’t tried that yet since it’s a 5TB job…
EDIT: It really seems to be a new problem that came with the new beta
Log entry:
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, Action`1 method)
at Duplicati.Library.Main.Controller.Backup(String[] inputsources, IFilter filter)
at Duplicati.Server.Runner.Run(IRunnerData data, Boolean fromQueue)
Might be unrelated but this looked a bit odd. I’ve changed to Swedish (which was included in the new beta, thanks!) and back to english testing the two.
Theses files have swedish or english filenames! Is that supposed to be?
Hmm…I could see that possibly causing an issue if not properly handled… Are you using the --prefix parameter? @kenkendk, are file names supposed to be translated?
As for the file-in-use error, could it be that Duplicati is now trying to back up your database files? I’ve seen one or two other posts that seem to show this happening…
Even if I set the job to backup just a single file, like a word document or something, I get this error. So it’s not a locked file among the files to be backed up.
But there’s an easy fix that I found. Just run a repair job separately first. Then run the backup. It seems that if I just run the backup job where it combines the repair+backup this error pops up. I’m not sure but I think I can get this error after manually stopping a job, perhaps in combination with that job starting with no local database.
…
Regarding the swedish filenames: No prefix parameter set.
I think this wouldn’t be the normal –prefix option anyway. These are backup database files, so it would be translating backup. As noted, translations got better in the new beta, and seemingly not very long before.
From the above, I’d guess that the intent is to translate to whatever language you are in at DB backup time. Possibly you could look at other messages to see what you were using when your database got backed up.
I was switching between english and swedish so the filenames were certainly created properly according to the current language. No problem there IMHO. I was just surprised that something like filenames would follow the chosen UI-language. Since I don’t know when and how Duplicati use these backup files I have no idea if this matters. But if they are created under one language how will Duplicati find them if I switch to another language later (most system software is in english so even if my local language is available it’s not safe to say I’d stick to Swedish anyway).
Actually on a sidenote, I’d prefer the UI in english but I’d like the 24h clock (don’t like AM/PM). So I tried Swedish for that. But went back to English.
Downgrading / reverting to a lower version gives some explanations on when those files are created, and how they’re used. The current answer seems to be that you have to figure out what they used to be to downgrade. Preferably that will be made a little easier in the future, and if it’s ever automated, then your point will kick in…
I can confirm that “System.IO.IOException: The process cannot access the file because it is being used by another process.” on the database itself is solved by:
First run a repair job
Then run the backup job
If I run the backup job directly, the repair starts first in that job and then fails on the locked file.
…
This problem started with the 2.0.4.5 beta. The error started popping up on jobs I stopped mid run. When restarting them I get this error. I think but I’m not 100% sure that the jobs I stopped mid run where jobs without a local database but with a complete set of backup files.
…
I’ll make a new thread on this so it’s not buried here under an older version thread