hyper-v: fix restores with portable data

[sebsura]

Thank you for contributing to the Bareos Project!

During restore the filedaemon only checks whether to restore portable data or normal data during the createFile() call. This is only called if plugins do not create the files themselves.

This means that if a plugin creates the file itself, then the filedaemon on windows will always think it is handling windows backup data. If the plugin now choses to do the restore via io_in_core, bareos will try to write portable backup data with the special windows backup functions, which will not work.

This would always have been a problem for plugins that mix and match io_in_core during backup/restore, but those did not exist. Now that we always treat plugin data as portable during backups, this is even a problem for plugins that only do io_in_core on windows (and create the files in the plugin), as during backup the core will backup the data via the portable methods, but as mentioned above, will try to restore with the windows specific ones.

Sadly this is the case with the new hyper-v plugin. As a quick fix this reverts the change to the portable data.

Please check

• Short description and the purpose of this PR is present above this paragraph
• Your name is present in the AUTHORS file (optional)

If you have any questions or problems, please give a comment in the PR.

Helpful documentation and best practices

• Git Workflow
• Automatic Sourcecode Formatting
• Check your commit messages
• Boy Scout Rule

Checklist for the reviewer of the PR (will be processed by the Bareos team)

Make sure you check/merge the PR using devtools/pr-tool to have some simple automated checks run and a proper changelog record added.

General

• Is the PR title usable as CHANGELOG entry?
• Purpose of the PR is understood
• Commit descriptions are understandable and well formatted
• Required backport PRs have been created
• Correct milestone is set

Source code quality

• Source code changes are understandable
• Variable and function names are meaningful
• Code comments are correct (logically and spelling)
• Required documentation changes are present and part of the PR