RCLONE.CONF file deleted due to network glitch - any way to ensure doesn't occur again?

[mjpcomp]

I've been getting notified via IFTTT that the backup to Onedrive has been occurring every time I connect to a saved WiFi (work/home) - but, the past few days, it's been the same (number of event/files)... That seemed weird to me, so, I SSH'd and tail'd the archiveloop.log:

Sure enough, running "rclone lsd onedrive:" resulted in nothing found in the config.. I checked out the config file path - empty...

The following occurred a few days ago:

It looks like the rclone config file got wiped out during that event (last modified date stamp of the config folder is the same).

Just thought I would make this issue known in case someone else encounters it - haven't had a chance to look through the code to see what would cause the rclone config file to be overwritten (other than rclone itself trying to reauth/renew, assuming it does that)... Maybe need to have a check where if the rclone config file doesn't exist, or is 0 bytes, then have IFTTT push a different message out, rather than a backup message (meaning, we probably need to get a check-routine to make sure the file exists).

[mjpcomp]

A look at the directory (prior to me recreating the rclone.conf - there was a 0 byte file that was modified at the same time as the error above):

[marcone]

I don't use rclone myself, and that part of teslausb mostly got inherited from the original upstream project, so I don't know much about it. Does rclone.conf actually need to be writeable (which is presumably why it's on /mutable), or could it be read-only in /root ?

[mjpcomp]

I don't use rclone myself, and that part of teslausb mostly got inherited from the original upstream project, so I don't know much about it. Does rclone.conf actually need to be writeable (which is presumably why it's on /mutable), or could it be read-only in /root ?

Understood on the usage - it definitely needs to be RW since tokens get updated (similar to the refresh token for Tesla). In my instance, my config file that I recreated yesterday for OneDrive has already been updated with a new token.

I still don't know what caused the file to be overwritten with a 0-byte file, but, it does look like it occurred during a failed connection attempt (maybe moved out of range, or something, looking at the screenshot from the first message in this thread). But, even a simple monitor before calling the rclone scripts (if the config file is 0 bytes, issue a warning if using an alerting method). Still haven't been able to take a look through the code, but, hopefully will get a chance to see if there's anything that can be done, error-checking wise.

[mjpcomp]

So, looks like this happen quite often... The file will be replaced with a 0-byte file - I have been able to keep a backup file that I cp back into place, and then, when I run "rclone lsd <name_of_cloudstorage>:" it will refresh the config and update the tokens.

I'm wondering if a small check needs to be placed into the rclone archiving script where it will, before calling or doing anything, perform the following:
If rclone.conf > 0 bytes, copy as backup to rclone.conf.backup
Proceed with normal archiving..
If rclone.conf = 0 bytes or does not exist, and rclone.conf.backup exists, copy to rclone.conf

This is just a simple way - I'm guessing the writing of the 0-byte file has something to do with lack of connectivity/resolution, and some error within rclone itself, but, only speculation without having looked into the code.