Yeah, that seems like the best way forward.
After playing around with it some more, I figured it out, in which the BackInTime developers should use a better method instead of only “udev”.
The filesystem’s UUID becomes immediately available upon plugging in the USB device. Without a built-in delay, the command to backup (via BackInTime) tries to run immediately when the USB is plugged in.
However, the filesystem being detected (its “UUID” is known immediately) is not the same as the filesystem being mounted. THIS is the reason for its failure.
Not to mention, many users do not enable “auto mount” for their removable devices. (In my case, I need to manually permit a USB to mount. I do not allow it to mount on its own.)
Speaking of which, a better method (instead of only “udev”) could probably use the mtab. In other words “When the MOUNT PATH is active, only THEN try to run the backup task.”
So it would be a two-part logic:
-
Upon inserting the relevant USB device,
udevwill trigger step 2… -
…which now polls the
mtabevery 5 seconds until the mount path is active.
If everything checks out, the backup task runs!
Otherwise, maybe after one minute, if the mount path is never active, only then will it fail and abort with the message “Mount path for the backup location was not available for over a minute. Backup task will not proceed. Please try again later.”
This thread can be shared with the developers.