Restore speed with Duplicacy is quite slow, can that be improved?

Related question: why is a path stored and not the content of the (conveniently json) token file itself?

Not only encrypting path to file has no value ( encrypting contents of the file would — but I would totally expect the file (that ends up in Downloads folder btw — transient location) to be safe to delete once it has been ingested by the app.

Same goes about the duplicacy CLI — the content of the token json should be incorporated into the preferences file or keychain, not path, because path to external files is unobvious and prone to data loss when user inevitably deletes that external file because there is no indication that only link is saved

I agree this is awkward. The fix I have in mind is to make the CLI take either the path or the content – if the input looks like a path and the file does actually exist, then treat it as a path; otherwise accept the input as the content of the token.

It would add one more step for the user - since it is received as a file: open json, remove line feeds (otherwise it becomes awkward to paste to CLI — end with empty line? What if there is empty line by accident?), copy and paste.

I think accepting the file, as today, but storing its content as opposed to path in the preferences file and duplicacy.json would be more streamlined and seamless change.

1 Like

@gchen can you say something about that? will I have to compile it myself, or do you maybe plan to merge that PR in the next few days anyways? Is anything blocking it that prevents you from merging it? Seems a bit surprising to me that you did not merge your own PR that’s already 1.5 months old now.

This is a feature that I expect will not be used by many people so I don’t know if I want to merge it.

what is the potential downside to merging it? does it change anything in any negative way in any circumstance? I thought it just makes use of some fields in that json file that would otherwise be ignored?

And in general, how likely do you find it that my slow restore speeds are caused by the things mentioned in this thread, and potentially fixed by changing that account setup that I need that PR for?

When you enable the debug level logging by adding the -d global option you’ll see rate limiting messages if there are. Unfortunately you can’t add a global option on the restore page, but you can run the CLI directly:

cd C:\Users\username\.duplicacy-web\repositories\localhost\restore
C:\Users\username\.duplicacy-web\bin\duplicacy_web_win_x64_2.7.2 -d restore -r revision -threads 4

I would find this PR useful as it seems really inconvenient to have the refreshing token file. What I’m unsure is if with this PR, it would still be necessary to keep the gcd-token.json somewhere on the machine, which is my main concern as that is not encrypted.

Additionally, I ran into a problem when I want to setup a second PC and the gcd-token.json has already expired. Then, it doesn’t work anymore. Will the backup on my first PC continue to work with the original gcd-token.json when I remove and re-add duplicacy to generate a new gcd-token.json?

1 Like

This sounds like the best idea and most convenient for users. It would also have the benefit for web edition users that the gcd token would be encrypted.

1 Like