Duplicacy Web UI OSX won't restore files

Support
#21

Thanks for the tips. I’ve tried with the + and without. I receive the same result on any file that’s within the boundaries of selections that will not restore (which is most of the files). I’ve tested with the + and without for files that will restore and it works either way. I can conclude the addition of the + has no effect whether a file will or won’t restore.

I can confirm I am not typing the filename by hand and am retrieving it directly from the restore attempt logs when the unsuccessful attempt is staged from the GUI. I’ve also retrieved it from the exlusion filters when specifying -d when it attempts to restore and shows it’s excluded. We’re working with this file for the purposes of this demonstration but I can assure you this filename exists, is correct, and the behavior is exhibited with other files.

Thanks for everyone’s help trying to work through this. I’m ready to purchase a business license because I believe in this product and like the community of support. I just want to get past this pretty large issue before doing such and unfortunately my trial is up tomorrow.

#22

Can you post the output of this restore command?

/Users/user/.duplicacy-web/bin/duplicacy_osx_x64_2.6.2 -d restore -r 598 -- "ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg" | grep 2060917

Again, please check if the file to be restored already exists. If it already exists with the same timestamp and size then Duplicacy will not attempt to overwrite it.

Please PM me the hostname and the public IP so I can extend the trial for you.

#23

Here is the output grepped for just that file. As you can see the file gets excluded, but the name and path match the original command. Smart suggestion I might say to do that and exclude potential I screwed up the path!

user@Mac Restore % /Users/user/.duplicacy-web/bin/duplicacy_osx_x64_2.6.2 -d restore -r 598 -- "ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg" | grep 2060917                                             
+ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg
 ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg is excluded
 ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg is excluded

EDIT: I should add, even though I’m working in an initialized alternate location that doesn’t include the file I’m trying to restore, I temporarily moved from it’s original backed up location and tried this as well with no luck. Good test though

#24

Did you add an extra space to the beginning of the last 2 logs to line up file names?

How about using wildcard matching:

/Users/user/.duplicacy-web/bin/duplicacy_osx_x64_2.6.2 -d restore -r 598 -- "ASSETS/Smith Slideshow/GFX/*2060917*" | grep 2060917

Please copy and paste the output and enclose with 3 backtick characters (```), without manual modification.

#25

Same result as before. Also, not modifying spacing. Copied out of terminal into post editor directly.

user@Mac Restore % /Users/user/.duplicacy-web/bin/duplicacy_osx_x64_2.6.2 -d restore -r 598 -- "ASSETS/Smith Slideshow/GFX/*2060917*" | grep 2060917
+ASSETS/Smith Slideshow/GFX/*2060917*
 ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg is excluded
 ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg is excluded
#26

Well I feel like I have a really sincere apology to submit for wasting your time. In complete transparency, this is not my data and I’m setting it up for someone else (if that can be accepted as an excuse). I just realized that all these folders are prepended with a space because the user wants them sorted at the top of their Finder view.

ASSETS
DOCUMENTS
MASTERS
PROJECTS

All of these directories are not prepended with a space.

Project Backups
Purchased

So you were definitely onto something when you asked if I was editing that output. The second batch of directories restore just fine. This seems to be breaking the restore having that space at the beginning of the directory name, I’m wondering how to mitigate the issue or resolve without asking the user to change their directory names (they have many projects that depend on the data structure).

It seems unlikely there are any modifications to the restore request I can make to WebGUI to mitigate, but is there anything in the CLI syntax? I’m open for suggestions on both.

EDIT: I can mitigate the issue in the CLI by using the + sign at the beginning of the restore request. So more apologies due for spreading false information that wouldn’t make a difference. It does in this case!

user@Mac Restore % /Users/user/.duplicacy-web/bin/duplicacy_osx_x64_2.6.2 -d restore -r 598 -- "+ ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg" | grep 2060917
+ ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg
 ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg is included by pattern + ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg
 ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg is included by pattern + ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg
Downloading  ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg
Prefetching  ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg chunk a048bbac8d3af592e1542c0c3dbc6c6b0f749da062fdbb07795480ed0387033e
Updating /Volumes/ArecaTest/Restore/ ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg in place
Downloaded  ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg (251208)
#27

No I think it is the other way around – the web GUI should have handled this case properly so I should apologize for wasting your time. I’ll fix this in the next release.

As for the CLI workaround, you really don’t need the + sign. A leading space should be enough:

Restore % /Users/user/.duplicacy-web/bin/duplicacy_osx_x64_2.6.2 -d restore -r 598 -- " ASSETS/Smith Slideshow/GFX/texture-2060917_960_720.jpg"

A + sign is only needed when there are exclude patterns (those starting with -).

#28

Interesting outcome. BTW, I know it might not look great for everybody, but I’ve always used an exclamation mark followed by a space to achieve the same thing:

! DOCUMENTS

Leading and trailing spaces - especially in directory names - have always caused issues for me in one way or another.

#29

I’m a fan of underscore personally.

_DOCUMENTS

Looking forward to the next Web GUI release with the fix! What kind of release schedule are you on @gchen? It looks to be about monthly.

#30

+1! :raised_hand: :grin:

#31

Let me correct myself – it is the argument parser in the CLI that swallows the leading space, which means restore " ASSETS/..." would not work and the + sign is required.

I don’t actually have a fixed release schedule, but a new release should be out in a week or two.

#32

Thanks for that clarification. It helps clear up any lingering confusion. One question I had after our testing exercises performed above. I had initialized /Volumes/Test/Restore as a repository. Do I need to clean that up? I don’t see it listed in Web GUI under storage.

#33
#34

I notice this is still an issue @gchen. Is it possible to get a fix in for restores that contain a preceding space in the root folder name working through the GUI? As I recall you can do this from the command line by adding a “+” to the inclusion list for the folder that has a preceding space in it’s root, but would love full compatibility in the GUI

#35

Disregard my bump on this. I’m a complete fool and thought Duplicacy was auto-updating. I updated to latest and restores are working now in GUI for directories that begin with a space