ATIH needed to manually re-create job a 2nd time
When I upgraded to ATIH2020 I had to manually re-create an existing job to get it to work.
Now after some months on ATIH2020 I've had to do so again.
In both cases aimply cloning the job wasn't enough, I had to manually re-create it.
Hope this won't become routine...but thankfully manually re-creating the job solves the issue.
FYI here's the log of one of the failures:
10/6/2019 2:52:28 PM: -07:00 280 I00000000: -----
10/6/2019 2:52:28 PM: -07:00 280 I00000000: ATI Demon started. Version: 24.4.1.21400.
10/6/2019 2:52:28 PM: -07:00 280 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
10/6/2019 2:52:28 PM: -07:00 280 I00640002: Operation (1)Old-C started manually.
10/6/2019 2:52:29 PM: -07:00 280 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
10/6/2019 2:52:29 PM: -07:00 280 I013C0000: Operation: Backup
10/6/2019 2:52:29 PM: -07:00 280 I0064000B: Priority changed to Low.
10/6/2019 4:50:22 PM: -07:00 280 E00000000: Error 0x40011: The specified file does not exist.
| line: 0xc8d8731ce106f9c3
| file: c:\bs_hudson\workspace\1168\archive\ver3\adapter\error.cpp:53
| function: `anonymous-namespace'::ConvertArchive3Error
| line: 0xc8d8731ce106f9c3, c:\bs_hudson\workspace\1168\archive\ver3\adapter\error.cpp:53, `anonymous-namespace'::ConvertArchive3Error
| $module: archive3_adapter_vs_21400
10/6/2019 4:50:22 PM: -07:00 280 E00040011: Error 0x40011: The specified file does not exist.
| trace level: error
| line: 0xc8d8731ce106f9c3
| file: c:\bs_hudson\workspace\1168\archive\ver3\adapter\error.cpp:53
| function: `anonymous-namespace'::ConvertArchive3Error
| line: 0xc8d8731ce106f9c3, c:\bs_hudson\workspace\1168\archive\ver3\adapter\error.cpp:53, `anonymous-namespace'::ConvertArchive3Error
| $module: archive3_adapter_vs_21400
10/6/2019 4:50:23 PM: -07:00 280 E013C0005: Error 0x13c0005: Operation has completed with errors.
| trace level: error
| line: 0x9f2c53c72e8bced6
| file: c:\bs_hudson\workspace\1168\products\imager\demon\main.cpp:736
| function: main
| line: 0x9f2c53c72e8bced6, c:\bs_hudson\workspace\1168\products\imager\demon\main.cpp:736, main
| $module: ti_demon_vs_21400
Start: 10/6/2019 2:52:28 PM
Stop: 10/6/2019 4:50:23 PM
Total Time: 01:57:55
As always thank you very much Steve! I'll attach the backup_worker log; it looks to me that it was the backup file G:\ati\Old-C-0002.tibx which couldn't be opened (which makes sense since the failure occurs during Verify).
Oh, and I decided to take this opportunity to run hardware diagnostics on the PC. So far I've only had time to determine (with HD Tune, my favorite) that the source and target HDDs are physically AOK. (I'll proceed to test RAM etc. ASAP.)
Yes, the backup_worker log does confirm an issue opening G:\ati\Old-C-0002.tibx which gets repeated after various error retries.
10/06/2019 23:39:01 type=log; level=inf; message=
ar#1: Successfully validated 14 ctrees, 150384KB total;
10/06/2019 23:39:01 type=validation; stage=trees; value=0; id=1
10/07/2019 00:50:22 type=log; level=err; message=
io: failed to open '\\?\G:\ati\Old-C-0002.tibx' (win_err=-2);
10/07/2019 00:50:22 type=log; level=err; message=
io#1: failed to open "\\?\G:\ati\/Old-C-0002.tibx" (pcs_err=-8);
10/07/2019 00:50:22 type=log; level=err; message=
io#1: read 0x20000 err -5022, offs 0x2db2d23000 in vol:2:0x4ae1000;
10/07/2019 00:50:22 type=log; level=err; message=
io: failed to open '\\?\G:\ati\Old-C-0002.tibx' (win_err=-2);
10/07/2019 00:50:22 type=log; level=err; message=
io#1: failed to open "\\?\G:\ati\/Old-C-0002.tibx" (pcs_err=-8);
10/07/2019 00:50:22 type=log; level=err; message=
io#1: read 0x400000 err -5022, offs 0x2db3095000 in vol:2:0x4e53000;
10/07/2019 00:50:22 type=log; level=err; message=
ar#1: failed to read segment 1606565 0x2db2d23:0x1 in vol:2:0x4ae1000 (err=-5022);
Thank you Steve. Since the HDD is AOK, and since re-creating the job solves the issue, I imagine the issue somehow flows from a corruption of jobs.
I'll post again if something else like RAM errors or filesystem correction shows up during further testing.