Snapshot policy broken in 2.0.3.7?

I upgraded over the 2.0.3.6 installation and now in addition to the temp file issue, the backup will no longer run if I set snapshot-policy to require. Logs says Duplicati cannot access the drives (eg. E:\ and F:) which are selected for backups. Removing snapshot policy allows the backup to run but then obviously no VSS.

I’m getting this too.

Warnings: [ 2018-06-20 13:28:07 +10 - [Warning-Duplicati.Library.Main.Operation.Backup.FileEnumerationProcess-FileAccessError]: Error reported while accessing file: F:\ 

I’m having the same problem here, the error only happens when VSS will copy data from the entire drive.

Ex: D:\

With pointing to a subfolder the error does not occur.

Ex: D:\test\

Can any of you confirm whether or not you are using a custom usn-policy OTHER than the default of off?

--usn-policy
This setting controls the usage of NTFS USN numbers, which allows Duplicati to obtain a list of files and folders much faster. If this is set to “off”, Duplicati will not attempt to use USN. Setting this to “auto” makes Duplicati attempt to use USN, and fail silently if that was not allowed or supported. A setting of “on” will also make Duplicati attempt to use USN, but will produce a warning message in the log if it fails. Setting it to “required” will make Duplicati abort the backup if the USN usage fails. This feature is only supported on Windows and requires administrative privileges.
Default value: “off”

@PhoenixAlpha & @SirFritz, do you have the same experience as @paulinhoocx where the VSS issue only happens when using the drive root?

@kenkendk, this might need to be addressed in the very next release…

I do not use usn-policy, but I’ve enabled it to test here and the problem remains the same.

I can confirm that the 2.0.3.8 canary version still exhibits the issue of an "Error reported while accessing file: X:\ " when using VSS --snapshot-policy=auto is used. :frowning:

Jun 28, 2018 12:32 PM: Error reported while accessing file: E:\
{
"ClassName":"System.IO.IOException",
"Message":"(123) The filename, directory name, or volume label syntax is incorrect: [\\\\?\\GLOBALROOT\\Device\\HarddiskVolumeShadowCopy26]",
"Data":null,
"InnerException":null,
"HelpURL":null,
"StackTraceString":"  
 at Alphaleonis.Win32.NativeError.ThrowException(UInt32 errorCode, String readPath, String writePath)  
 at Alphaleonis.Win32.Filesystem.File.GetAttributesExCore[T](KernelTransaction transaction, String path, PathFormat pathFormat, Boolean returnErrorOnNotFound)  
 at Duplicati.Library.Snapshots.SystemIOWindows.GetFileAttributes(String path)  
 at Duplicati.Library.Utility.Utility.<EnumerateFileSystemEntries>d__23.MoveNext()",
"RemoteStackTraceString":null,
"RemoteStackIndex":0,
"ExceptionMethod":"8
ThrowException
AlphaFS, Version=2.1.0.0, Culture=neutral, PublicKeyToken=4d31a58f7d7ad5c9
Alphaleonis.Win32.NativeError
Void ThrowException(UInt32, System.String, System.String)",
"HResult":-2147024773,
"Source":"AlphaFS",
"WatsonBuckets":null
}

I’ve gone ahead and flagged this topic as a #bug and entered an issue at GitHub.

Note that this problem seems to be loosely related to an issue over at GitHub in that I was also seeing a pair of the following errors in the Windows Event Log with each job run:

Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback interface.  hr = 0x80070005, Access is denied.
. This is often caused by incorrect security settings in either the writer or requestor process. 

Operation:
   Gathering Writer Data

Context:
   Writer Class Id: {e8132975-6f93-4464-a53e-1050253ae220}
   Writer Name: System Writer
   Writer Instance ID: {8a2ed07d-28e3-44a6-af17-6ac7460ff262}

While adding --vss-exclude-writers={e8132975-6f93-4464-a53e-1050253ae220} DID stop the errors in the event log, it did not allow the root-based backup with VSS to work correctly.


On top of all that, in the GUI the job run is listed as a SUCCESSFUL backup. I believe this is because the “error” is recorded as a WARNING.

I suspect this by design so that issues with one source “folder” won’t necessary kill backing up other ones. In my job the drive root is the ONLY folder so the “warning” probably should be treated as an actual error.

I think that is unrelated. It sometimes happens that a VSS writer is installed from some third-party tool that causes snapshots to fail.

This happens because the source folder is actually found. If it was not found, the backup would stop unless you have --allow-missing-sources added. But since the source is found and working (before VSS), the backup continues. When VSS kicks in, there is “some problem” accessing it, which causes the warning. If this had not been the backup root folder, it would make more sense that it was a warning.

The logic for treating it as an error is a bit convoluted: if a source folder has not contents, and a single error, then it is an error otherwise a warning. But we should change that.

We have not changed anything related to VSS, so I am not sure why this starts happening. As you discovered, it only happens if you make a full drive backup. From the error message, I am thinking it is something simple with the UNC path not having a trailing slash or something.

Edit: there was a refactoring change, I think that broke it somewhere:

Ok, I think I have a fix now (need to test it first):

Apparently the problem occurred with other combinations of VSS usage, than just the naked drive.

I reverted the code to use manual path construction, as it appears that Path.Combine does weird things when one path is \?\\GLOBALROOT\.

Will merge as soon as the unittest passes and then send out a new canary with the fix.

@PhoenixAlpha, @SirFritz, and @paulinhoocx - I have tested for this issue in 2.0.3.9 and it does appears to be fixed for me.

Can any of you confirm that?

Fixed issue in version 2.0.3.9, the backup now runs without any VSS errors. Thank you.

@kenkendk @JonMikelV

Thanks for the confirmation!

I’m flagging “update to 2.0.3.9” as the “fix”, marking this #bug as #fixed , and closing the topic.