Restore broken on windows with new WebUI and cli 2.2.0

Please describe what you are doing to trigger the bug:
Restore a file from wasabi to a specified directory

Please describe what you expect to happen (but doesn’t):
The file should be restored into the directory

Please describe what actually happens (the wrong behaviour):

2019-05-14 13:07:23.550 INFO RESTORE_START Restoring C:/Users/XXX/Desktop to revision 52
2019-05-14 13:07:23.563 ERROR DOWNLOAD_CREATE Failed to create the file \\?\C:\Users\XXX\Desktop\Confocal\2018-08-23\Filtered 0.5% 100-100 in-out.lifext for in-place writing

Gui 2.1.2 restores correctly the same file, same for web ui with cli 2.1.2

I couldn’t reproduce this, but I found a different bug where restoration of files with spaces in the name will not be reported by the web GUI.

The error in your case may be caused by the existing file not being writable.

Duplicacy fails to create the file in an empty directory

Same problem, same versions except I’m using local storage. Here is the log:

2019-06-01 21:08:17.783 INFO REPOSITORY_SET Repository set to C:/Users/XXX/Downloads
2019-06-01 21:08:17.783 INFO STORAGE_SET Storage set to D:/suno_bk
2019-06-01 21:08:17.783 INFO SNAPSHOT_FILTER Loaded 1 include/exclude pattern(s)
2019-06-01 21:08:17.800 INFO RESTORE_INPLACE Forcing in-place mode with a non-default preference path
2019-06-01 21:08:18.190 INFO SNAPSHOT_FILTER Parsing filter file \\?\C:\Users\XXX\.duplicacy-web\repositories\localhost\all\.duplicacy\filters
2019-06-01 21:08:18.190 INFO SNAPSHOT_FILTER Loaded 0 include/exclude pattern(s)
2019-06-01 21:08:19.734 INFO RESTORE_START Restoring C:/Users/XXX/Downloads to revision 13
2019-06-01 21:08:19.744 ERROR DOWNLOAD_CREATE Failed to create the file \\?\C:\Users\XXX\Downloads\Documents\christie-reading-list.pdf for in-place writing

New user testing Duplicacy. I have the same issue. Web GUI does not restore anything with the same error as above.

It may or may not be related (not quite sure if the GUI version uses the same CLI backend as the Web UI) but I am having similar issues with the GUI interface. That will restore some of the files, but not all of them. For example, in a folder of photos, it will restore files fine from a directory called “2019”, but not from a directory called “iPhone”.

I can use “View” to see the files it won’t restore (well, I get the few ASCII chars showing the EXIF code at the start), so they appear to be in the backup, plus get “restored”, but just won’t write to the folder for some reason.

More info - if I replace the duplicacy_win_x64_2.1.2.exe executable in the GUI version with duplicacy_win_x64_2.2.0.exe downloaded from GitHub, and rename it back to duplicacy_win_x64_2.1.2.exe (so the GUI finds it), everything works. Go back to 2.1.2 and the GUI doesn’t restore some files (with no errors either).

This implies the CLI version 2.2.0 does work, but Web UI 1.0.0 doesn’t. But my solution is very hacky for such a mission critical piece of software.

Edit (not allowed more than 3 responses!)

More messing around with the Web UI reveals this problem is when you choose a different folder to restore to than where the backup originated from. If you restore in place, the Web UI works. Given an (empty) .duplicacy folder appears in the new location, I am inclined to believe the error is a failure of the info required by the CLI version to be correctly populated in that .duplicacy folder by the Web UI when handling a restore to an empty folder.

I don’t understand why you need to do all of this, unless you manually specified that you don’t want the web UI to take CLI updates as they’re released (as mentioned in this post).

Did you manually hard code an older CLI version in duplicacy.json for the web UI?

That was with the legacy GUI version, not the Web UI one. I was just trying to get any version to work.

If you’re seeing this error:

2019-06-03 07:58:15.035 ERROR DOWNLOAD_CREATE Failed to create the file \\?\C:\Temp\repository\dir1\file1 for in-place writing

This can be caused by the parent directory not being writable.

@ralph, if restore runs to completion without actually restoring the file, then it is a different issue, caused by a bug interpreting the file name as a regex, which has been fixed in 2.2.0 by this commit: Fixed a bug where filenames starting with i or e are mistakenly inter… · gilbertchen/duplicacy@abcb4d7 · GitHub

1 Like

It’s not a read only directory error. I can try to restore to a completely new directory and the error still happens using the Web UI.

The regex fix will explain why replacing the 2.1.2 version in the legacy GUI directory with the 2.2.0 version makes it all work. Especially as the folder that was failing to restore began with an “i”.

1 Like

Cannot restore single file from directory. Error message

2019-06-04 12:58:40.572 INFO REPOSITORY_SET Repository set to C:/RESTORE
2019-06-04 12:58:40.636 INFO STORAGE_SET Storage set to C:/TEST
2019-06-04 12:58:40.636 INFO SNAPSHOT_FILTER Loaded 1 include/exclude pattern(s)
2019-06-04 12:58:40.666 INFO RESTORE_INPLACE Forcing in-place mode with a non-default preference path
2019-06-04 12:58:40.698 INFO SNAPSHOT_FILTER Parsing filter file \\?\C:\Users\arty\.duplicacy-web\repositories\localhost\all\.duplicacy\filters
2019-06-04 12:58:40.699 INFO SNAPSHOT_FILTER Loaded 0 include/exclude pattern(s)
2019-06-04 12:58:40.699 INFO RESTORE_START Restoring C:/RESTORE to revision 1
2019-06-04 12:58:40.700 ERROR DOWNLOAD_CREATE Failed to create the file \\?\C:\RESTORE\api\api-versions.xml for in-place writing

It looks like the program cannot create a directory before restoring a file. Because if I restore the whole directory, everything is fine. If i create a directory in advance, the file is restored without errors

@gchen is this a permission issue of sorts?

@Arty.R can you try to restore with -ignore-owner option? (if there’s a way to pass these arguments from web-ui)

Not working
with -ignore-owner option the same error

maybe there is an option to force create directories?

The directory C:/RESTORE exists already, right?

I can confirm this is a bug in the CLI version affecting Windows users. The workaround is to manually create the parent directory before restoring the file. Restoring directories is not affected.

I’ll roll out a fix later today.


CLI version 2.2.1 has been released, so you can just restart Duplicacy Web Edition and it will automatically download the new CLI version which fixed this restore bug. Unless you have locked the CLI version in ~/.duplicacy-web/duplicacy.json in which case you’ll need to update the CLI version key (see CLI 2.2.0 has been released (impact on the Web GUI)).

So this bug is #fixed, right?

The bug I posted has been fixed, restore now works normal…I don’t know about the other users that also posted on this thread

1 Like

This topic was automatically closed 12 days after the last reply. New replies are no longer allowed.