I am getting the error “Copying snapshots to XXX was disabled by the preference” when trying to copy snapshots from one storage to the other.
What does that mean and how can I overwrite that?
I am getting the error “Copying snapshots to XXX was disabled by the preference” when trying to copy snapshots from one storage to the other.
What does that mean and how can I overwrite that?
You have "no_backup": true
in the .duplicacy/preferences
file which disables backup and copy.
Thanks. And when and why is that set? It seemed to appear after doing a check or backup, but I didn’t verify in detail.
How did you run the copy command?
I ran
C:\ProgramData.duplicacy-web\bin\duplicacy_win_x64_2.6.1.exe copy -threads 3 -from storage1 -to storage2
Which completed w/o error. After that I ran a check, which showed missing chunks. I then tried to run the copy command again and got the error that copying is disabled.
The preferences
file is updated every time a job is run by the web GUI. Can you just run a copy job in the web GUI (by creating a schedule, adding the copy job, and then clicking the start button)?
I too have had this issue, and the problem happens for copy jobs run from the GUI.
My copy jobs are intermittently failing with this message (some days it runs, and some it fails with the “was disabled by the preference” message. Can you clarify what jobs in the GUI change this preference so I can work around the problem? I am guessing it might be something to do with a “check” job that runs at the same time as the copy job, but it would be good to clarify to understand that better.
Obviously it is probably not ideal to run a check at the same time as a copy for other reasons so i will probably change that anyway.
Copy, check, and prune jobs use the same repository location at ~.duplicacy-web/repositories/localhost/all
so they will all write to the same .duplicacy/preferences
. A check job sets no_backup
to true while a copy job sets it to false. So if a copy job runs at the same time as a check job at exactly the same time then a conflict may occur. The workaround is to disable the parallel
checkbox so they won’t run in parallel.
I’d like to reopen this question as I can reproduce it, and am confused about how it is supposed to work. So here is what I have done to trigger it:
This does not sound like expected behavior to me. A few questions:
Right, it is obvious now that setting this no_backup
flag is unnecessary. Probably a result of overthinking. I’ll remove it in the next release.
If you really want to get around this problem, just initialize a dummy repository under any directory (by running the init command) and then run copy from there.