@gchen I figured out the key to reproducing the bug:
- In web interface, select revision from the list, such that it’s ticked
- Leaving it selected, expand revision
- Select individual file, such that it’s ticked
- Deselect revision, so it is unticked, leaving only file ticked
- You will have all files restored
I had accidentally clicked the folder the first time, assuming it’d expand it - then clicked the expansion, then selected my file + deselected the top. I just didn’t realise that was the root cause, until I went to redo everything, and it only restored the single file - and then I realised the only difference in process was where I clicked. I reproduced it using the above in order to confirm.
To help, here was the rest of my process in creating the backup, just in case there is anything else specific about my setup that is required to trigger this:
- On Linux server, web edition (running as root), make new backup located in /home/user/temp
- Initialise storage with password + RSA key
- Create backup of the given directory with those files, backup ID
test
- Change threads to 10
- Complete backup
- Move over to Mac
- Add storage on Duplicacy web for Mac (accessed over SFTP - if relevant, auth is done via the Tailscale SSH agent rather than keyfile, and accessing as root for purposes of testing). Storage name + backup ID as test
- Restore to folder on Mac /Users/username/temp
- Restore in GUI with options
-key /path/to/key/duplicacy-private.pem -key-passphrase YourPassword -ignore-owner
- Select file to restore as per above process
Although unlikely to be required, also happy to provide the original files if needed for reproduction, or, the backup + associated private keys (which are all just testing keys)