I have a zero-byte duplicacy.json file inside .duplicacy-web directory. I suspect that is the cause of this problem. Is it safe to recover the file from one of the recent snapshots using the CLI (the .duplicacy-web directory is included in one of my duplicacy backup repositories)? Is there anything I can do to avoid having this problem in the future?
Y’know, today I was wondering why Duplicacy was re-hashing some of the token and password entries while I had it open in Notepad++, and whether it might become a problem. Perhaps it should write to a .tmp file first and rename?
If you can recover a recent duplicacy.json with CLI, I don’t think it’ll be a problem. Make sure to properly quit the program first.
At this point I am more interested in understanding the root cause of the problem. I wasn’t using the web UI to change any settings. I don’t have any reason to believe something else has overwritten it. I will attempt to recover the file or nuke and recreate the configuration later.
Same thing just happened to me. I also haven’t been making any changes but I did have it open in Notepad++ as part of comparing it to the file on another PC as part of another issue.
Did it try to updating it but fail due to notepad++ having a lock on it? Maybe a backup copy of it should be kept but duplicacy just in case.
Unlikely. Notepad++ is able to detect file changes on disk. It wouldn’t be able to do that if it kept an exclusive lock on the file. There must be a subtle issue somewhere. @gchen, when is duplicacy.json updated and rewritten?
@mlisasu do you see any relevant error messages in the log (~/.duplicacy-web/logs/duplicacy_web.log)? If it fails to update the config file it should print out the error to the log.
I had a look in my logs and there’s not much of use that I can see. There are working messages one day and then the next thing I see is me setting it all up from scratch again.
I also searched all my logs for duplicacy.json and found nothing.
edit. I was looking in the wrong place - these logs are huge. Anyway I did find something after all
2019/08/09 21:30:01 Set current working directory to C:\Users\Phil/.duplicacy-web/repositories/localhost/all
2019/08/09 21:38:15 The Duplicacy executable returned an error: exit status 1073807364, exit code: 1073807364
2019/08/09 21:38:15 err: exit status 1073807364, exitCode: 1073807364
2019/08/11 10:03:24 Failed to parse the configuration file: unexpected end of JSON input
2019/08/11 10:26:31 Created a new configuration.
2019/08/11 10:26:32 Duplicacy CLI 2.2.3
1073807364 is 0x40010004 which may mean Windows is shutting down. This is an error returned by Windows, not by Duplicacy. So I tend to believe there was something wrong your computer.
I think it just means duplicacy exited in a bad state when Windows was shut down. Generally speaking, configuration file updates need to be as close to atomic as possible to avoid situations like this one. Keeping a backup copy would also have helped.
This just happened to me again. I’m not doing anything other than a normal windows shutdown so I think the process of updating the json file needs to a lot more resilient.
I noticed version 1.1 is out now so i’ll update to that in case you made any improvements in this area.
This has just happened to me (Windows UI version). How do I fix it?
20:00:00.000 Command: duplicacy -background -log -d backup -stats -threads 6
20:00:00.828 Storage set to one://z-duplicacy-backups
20:00:00.829 Reading the environment variable DUPLICACY_GUI2_ONE_TOKEN
20:00:00.832 Reading one_token from keychain/keyring
20:00:00.832 Failed to load the OneDrive storage at one://z-duplicacy-backups: unexpected end of JSON inputThis looks like a race condition in updating the OneDrive token file by multiple threads at the same time. You should be able to fix it by redownloading the token file from OneDrive for Duplicacy.