Schedule command with blank password prevents subsequent schedule commands

[bryankitts]

On Windows, if a schedule command is run and a blank (incorrect) user password is entered, the command fails (as expected), but then subsequent schedule commands crash without prompting for a password (see attached output).

> resticprofile schedule --all

Creating task for user PC\User
Task Scheduler requires your Windows password to validate the task: 

[At this point I incorrectly just pressed Enter i.e. blank password]

2024/12/10 17:24:10 error creating job daily/backup: error creating registered task \resticprofile backup\daily backup: 
error registering task: The user name or password is incorrect.

> resticprofile schedule --all
uh-oh! resticprofile crashed miserably :-(
...

schedule_crash.txt

Opening a new command window doesn't resolve it i.e. same crash. I suspect logging off and on will fix it, so it's a very low priority to fix. Rebooting doesn't seem to fix it.

Not sure if the issue is caused by the password entered being blank or just incorrect. (My password is not blank, but I normally use a PIN to log on to Windows which is why I'd forgotten it.)

[bryankitts]

It seems the incorrect blank password got saved in Windows Credential Manager (as "MicrosoftAccount:user=email_address"). After deleting the entry, resticprofile schedule prompted again for a password and ran successfully.

(I'm logged into Windows using a Microsoft account rather than a local account - not sure if that makes a difference.)

[creativeprojects]

Thank you for the crash report.

(it's my first crash report in 5 years 🍾 )

I think saving this password in the Credential Manager is a (fairly?) new feature in Windows, because I never had the issue before (although I no longer use Windows since I changed job about 3 years ago 😆 )

I'll do some tests and see how I can prevent that 👍🏻

[bryankitts]

Thanks for looking at this, and sorry for breaking your 5 year streak!

I'm no longer sure about Credential Manager: the crash has come back (even running 'status --all') and deleting the entry no longer makes any difference, so it may just have been a coincidence.

I've also tried reproducing it under the debugger (VS Code on same PC) with mixed results. Almost every time I run it under the debugger, it completes successfully, but I had one run where I was stepping through some of the code and got exactly the same crash and call-stack.

Also, it has never prompted me for a password under the debugger. It's only ever asked me for a password twice outside the debugger: the very first time I ran it (when I accidentally entered a blank password), and the one time I successfully ran it after deleting the Credential Manager entry, when I entered my password correctly (and it then successfully created entries in Task Scheduler).

In summary, outside the debugger I've had one successful run and many crashes. Inside the debugger I've had one crash and many successful runs.

Let me know if there's anything I can try from my side. (I have dev experience but none with Go or VS Code, so feel free to suggest obvious things!)

[creativeprojects]

Thanks for trying this out.

I'll be on Xmas break next week so I'll dig up my old Windows laptop and try to make sense of it 👍🏻

[bryankitts]

Some more testing results. (Not sure how much they'll help.)

In summary, the original crash seems to be random and intermittent, and there are separate errors with unschedule (possibly due to my profiles.yaml being incorrect).

I tried resticprofile schedule --all on a different PC but using the same exe, config file, and (Microsoft online) user account. It worked perfectly, without even prompting for a password.

I then ran resticprofile schedule --all on the original PC, and it worked perfectly there too, again without needing a password. (I had rebooted in the meantime, but previously rebooting hadn't helped.)

To see if it was repeatable, I tried using resticprofile unschedule --all to remove the scheduled tasks so I could rerun, but this unschedule produced the original crash.

I immediately reran the same unschedule command, but this time got a different error:
error removing job common/backup: error deleting task \resticprofile backup\common backup: The system cannot find the file specified.
I think this is an unrelated issue since it seems to be trying to remove a job for the (non-scheduled) "common" profile, suggesting that unschedule --all isn't picking up the same groups/profiles as schedule --all.

Given this, I tried to remove each scheduled job individually with resticprofile daily.unschedule and resticprofile weekly.unschedule. Firstly I ran resticprofile daily.unschedule and got the original crash, immediately ran it again and got the same crash, and ran it a third time and... got a different error:

using configuration file: profiles.yaml
scheduled job daily/backup removed
error removing job daily/check: error deleting task \resticprofile backup\daily check: The system cannot find the file specified.

At this point the "daily" scheduled job had been deleted, so this "daily/check" error seems a similar issue to unschedule --all.

Finally I ran resticprofile weekly.unschedule and got the original crash the first time, and then the above behaviour the second time i.e. successfully removing the job but followed by "error removing job weekly/check".

(I then ran resticprofile schedule --all again, which crashed the first time but successfully completed the second time.)

Let me know if there's anything I can to to help with this e.g. move the unschedule errors to a separate issue.

(For me the workaround of "rerunning until it works" is good enough since I rarely need to change the backup schedule.)