Page 3 of 4

Re: Scheduled backup did not trigger

Posted: 14 Oct 2021, 10:59
by cobian
Hmm...interesting. Could you try to create 4 new tasks (the same ones, by cloning), and delete the 10 min event and see if it works as intended? I still think this is the problem.

Re: Scheduled backup did not trigger

Posted: 14 Oct 2021, 12:42
by przemhb
Would it be ok just to decrease those 10m to 10 seconds in the task I already have? Or you prefer I clone those tasks and change the value in the cloned one?
If the delay is indeed causing the issue, than I assume it is safe to reschedule the tasks for today (to not to wait for Monday), isn't it?

Re: Scheduled backup did not trigger

Posted: 19 Oct 2021, 23:50
by przemhb
On the 14th Reflector noticed backups of original tasks, which were scheduled to Monday the 11th, were missed and triggered all of them.

Later I've cloned original tasks and removed the 624 second wait time from the first clone's pre-backup events. After several attempts I've eventually managed to change schedule of those cloned tasks (later more about this).

Later the day Reflector triggered clones 1 & 2 as scheduled and they were processed just fine. Notably backup type of the 1st one was changed to a full, as it was the first time this task was to be run. Tasks 3 & 4 were not triggered.
The next day I have rescheduled the set of clones for a later hour the day. All of them were triggered. The 3rd type was changed to full.

This Monday none of the original tasks triggered as scheduled.
Today I have rescheduled the set of clones a few times, but they weren't fired. No idea why. Nothing in the verbose log.

I've noticed that if you reschedule time and day of a task and move to editing a next task immediately the change is not saved. I've discovered I need to wait until the rescheduled task's properties show new time. Only then I can move to editing an other task.

There's one more thing. I've found in the log a line as follows: "ERR 2021-10-18 18:32:11 An error occurred while creating the monolithic archive: File "E:\work\HPN-1\FW\.git\config\" not found". This is strange as "config" is a file and not a folder. And it was like this for years, as I have not modified the "E:\work\HPN-1\" since September 2020.

Re: Scheduled backup did not trigger

Posted: 20 Oct 2021, 08:10
by cobian
I've noticed that if you reschedule time and day of a task and move to editing a next task immediately the change is not saved. I've discovered I need to wait until the rescheduled task's properties show new time. Only then I can move to editing an other task.
Yes, the changes need to be "approved" by the engine and send back.
There's one more thing. I've found in the log a line as follows: "ERR 2021-10-18 18:32:11 An error occurred while creating the monolithic archive: File "E:\work\HPN-1\FW\.git\config\" not found". This is strange as "config" is a file and not a folder. And it was like this for years, as I have not modified the "E:\work\HPN-1\" since September 2020.
Will take a look at that.

Re: Scheduled backup did not trigger

Posted: 20 Oct 2021, 20:04
by przemhb
Yes, the changes need to be "approved" by the engine and send back.
But is it ok for Reflector to drop changes, which were in the process of approving, if user modifies another task in meantime? Shouldn't user been informed to hold with any further modifications or even blocked until previous ones get approved?

What about those cloned tasks, which I rescheduled a few times, but they didn't fired? Am I missing something here?

Re: Scheduled backup did not trigger

Posted: 24 Oct 2021, 14:03
by cobian
The time it take to send the changes to the engine and backup is around 800 ms (as maximum time) to the engine 800 ms back. So as max: aprox 1.5 seconds tot. I don't want to force this time to be quicker in order not to overload the inter-process communication. I'll make some tests.

Re: Scheduled backup did not trigger

Posted: 30 Oct 2021, 01:00
by przemhb
przemhb wrote: 20 Oct 2021, 20:04 What about those cloned tasks, which I rescheduled a few times, but they didn't fired? Am I missing something here?
The most important thing here is reliability. And Reflector still doesn't trigger my backups. I've removed the 624s wait time as previously described and it did not help. Yesterday I even deleted all the pre and post-backup events. None of the cloned tasks triggered today, as scheduled.

In the verbose log there are only two types of messages: "Getting the backup history for the task" and "The list "export.lst" has been successfully saved."
They appear on times other, than backup tasks' scheduled times.

Note also that Cobian Backup deals flawlessly with the pre and post backup events including the 624s wait.

What should I test now to help us tackle the bug?

Re: Scheduled backup did not trigger

Posted: 02 Nov 2021, 21:13
by przemhb
I've uninstalled old version and performed installation of the new .38. I guess it must have been something with the service as now all the backups triggered. I hope they'll fire every time as scheduled.

Re: Scheduled backup did not trigger

Posted: 02 Nov 2021, 21:31
by cobian
Nothing has been changed in this case so... maybe the same problem will arise

Re: Scheduled backup did not trigger

Posted: 07 Nov 2021, 23:57
by przemhb
For the last few days all tasks triggered just as scheduled.
Today I have noticed there's a new version so I updated the Reflector. During uninstallation process there were some errors:

Code: Select all

The file "C:\Program Files\tools\Cobian Reflector\Cobian.CommonX.CobEncryptX.dll" couldn't be deleted: Odmowa dostępu do ścieżki „C:\Program Files\tools\Cobian Reflector\Cobian.CommonX.CobEncryptX.dll”.
The file "C:\Program Files\tools\Cobian Reflector\Cobian.CommonX.CobListsX.dll" couldn't be deleted: Odmowa dostępu do ścieżki „C:\Program Files\tools\Cobian Reflector\Cobian.CommonX.CobListsX.dll”.
The file "C:\Program Files\tools\Cobian Reflector\Cobian.Reflector.Common.dll" couldn't be deleted: Odmowa dostępu do ścieżki „C:\Program Files\tools\Cobian Reflector\Cobian.Reflector.Common.dll”.
The file "C:\Program Files\tools\Cobian Reflector\Cobian.Reflector.Constants.dll" couldn't be deleted: Odmowa dostępu do ścieżki „C:\Program Files\tools\Cobian Reflector\Cobian.Reflector.Constants.dll”.
"Odmowa dostępu do ścieżki" = "Permission to the path denied".

Despite of this installation log declared installation was succesfull:

Code: Select all

The old instance has been uninstalled.
The installation has been completed without errors.
If the tasks cease to trigger tomorrow then it will be a clue, that it has something to do with those errors during uninstallation.
I use Kaspersky Internet Security and during the whole installation process I am asked plenty of times if I accept given operation on a file or a registry. Each time it takes me a second or a few to read the message box and accept the operation. For some executables I click I trust them.
Is it possible uninstallation timeouted for those 4 files? I am sure I did not denied any operation during the uninstallation process.