As it appears e:\ is a mounted share, can you give more details on the underlying mount, such as the operating system where the share exists as well as the os where Duplicati is running.
A quick test backing up from File Source to Webdav backend and restoring with folders containing & as part of the path worked fine, the escaping on the path is intriguing. Did you replace the servername/ip to ? for privacy or was this the actual output?
Unless the path starts exactly with \\?\ (note the use of the canonical backslash), it is normalized.
and this results in paths that are different getting seen as the same, confusing Duplicati…
I’m not sure, though, why it did \\?\e:\E\. Might it be thinking that drive letters are A-Z?
You’re not the intended audience. I was responding to @marceloduplicati about URL format.
Basically don’t worry if you see things with that start, because the code does it deliberately…
What bothers me is seeing e or E twice. I suppose you could see if uppercase E: does better, however your latest test looks like the E after testrestore came in out of nowhere? Quite odd.
I have no comment for the developers besides some history about the DOS device path use.
Did you make it minimal, e.g. no Advanced options (including Settings Default options), tiny file, etc.? I’ve been running that both on C: Source and with Source on a USB drive that landed at F:.
I’m testing restore of both the “Filme & Dokus” folder and the single (faked) .mp4 file in “Filme”. Getting lowercase f: took a manual edit, but still worked. I’m using Edge browser, if it matters…
Is this a GUI restore directly to a localhost address, or are there proxies that may be interfering?
I’m also a bit puzzled how you get lowercase drive letters. My GUI offers them up as uppercase, however for me it doesn’t seem to matter. Works either way.
Arh, so the problem is that the folder is not being restored (due to filters, sources, etc) and this causes the restore to fail restoring the file. The previous code would handle that with a warning and create the folder before creating the file.
I’m still looking for @Ralf answers to my two previous posts because I still can’t repro the issue. Anyone else who can do it, I think this may need more details, and ideally some exact test steps.
New code has some ability to create folders. Normally a GUI backup seems to checkmark higher folders. I used a CLI backup to give a deeper folder, basically giving no DB record of the highest.
and yet I had all of the upper folders created on CLI restore to F:\testrestore.
I’m also using --dont-compress-restore-paths=true to make it like error:
which has that full-path look, but I’d like to know what was asked, and how.
My only objection (since I can’t repro issue) is that time stamps weren’t set.
F:, Filme & Dokus, and Filme all have restore time. Only file got its old time.
First two above can be forgiven better, but Filme is actually in the database.
My CLI restore (since GUI worked) said to restore “f:\Filme & Dokus\Filme\”
@ts678 I’m not quite sure what exactly you mean. I’ll answer what I can, in case you miss sth let me know.
Yes. The test is a new backup-job with just standard settings and password set. (export-file see below)
Is this a GUI restore directly to a localhost address, or are there proxies that may be interfering?
What do you mean by this?
I’m also a bit puzzled how you get lowercase drive letters. My GUI offers them up as uppercase, however for me it doesn’t seem to matter. Works either way.
Yes, the lowercase letter was manual input, but as you mentioned selecting the restore folder from the GUI checkbox doesn’t change the error. Edge browser neither.
The localhost address shows up in the browser URL that you use. It browses on local system:
http://localhost:8200/ngax/index.html#/
If you were coming from another system, it would take more setup and URL would be different.
There is also a chance that there is some networking in between that messes with the request.
If this was necessary because you could not browse to the drive, note drive letters may vary by user, and you are possibly running Duplicati as a Windows service as SYSTEM user, and drive assignments possibly differ from what you see as you. You described E: once. What’s drive D:?
You can check About → System information line for UserName to see what user you’re running.
First line is where default Windows service job DB might land. Is this Duplicati run as a service?
Make very sure drive letters are what you think they are, if the user differs. Can you run as you?
First source line surprised me, as I expected a folder rather than a specific file to be backed up.
Second source line surprised me, as I was after simplest config that fails. Can you delete that?
I tried setting up something similar to yours, except running as me, and with only one Logs file.
On Restore screen, I pick Filme & Dokus, then only change the “Pick location” to F:\testrestore.
Works fine.
he localhost address shows up in the browser URL that you use. It browses on local system:
Ah, ok. And yes, it’s local
If this was necessary because you could not browse to the drive, note drive letters may vary by user, and you are possibly running Duplicati as a Windows service as SYSTEM user, and drive assignments possibly differ from what you see as you.
Actually I’m running Duplicati as service, but the drives show up fine in the GUI. Manual input was just faster at the moment.
But when checking About I noticed that there were still global options configured:
Thank you @Ralf and @ts678 for reporting the issue, for providing the detailed bug hunt, and for the bug reproduction steps! It has been fixed and merged in PR 5840, which also adds a CI test capturing the bug to prevent it from breaking in the future. It should be part of future releases.
Seems to be a bug with the new Restore routine.
