(Yesterday, 07:07 PM)admin Wrote:(Yesterday, 01:58 AM)Froggie Wrote:
OK, here's where I am with this (running v5.4.2.3)...
I currently have (2) tasks operating on the current System configuration, both are DISK/PARTITION tasks whose job is to save (5) of the (7) partitions on that disk. The (5) include all partitions (4) needed to successfully restore the UEFI System and (1) additional personal support partition. A geometry change was made to both the OS and Windows Recovery (RE) partitions with no other partitions being affected. Following that change, a manual FULL was generated, using task #1, to capture the geometric partition changes. When the FULL was examined under the RECOVER menu, it was shown to no longer contain the 2-partitions that were changed, only the 3-partitions that hadn't changed... no error of any kind was generated during the FULL manual image operation (scary). This occurred no matter what type of image I tried to capture in manual or scheduled mode.
I then created the 2nd task (under the current release) with identical settings to the first task, using a different task name, then captured a new FULL image of the System with the geometry changes included. After checking the image, all selected partitions (5 of them) were there.
The two tasks are now tracking the same System. Using task #2 (the newest task created under v5.4.2.3), if I make another geometry change to a single partition and run either a manual or scheduled imaging operation, I get the error stating about the unfound partition (as I'm told is expected). If I run the same operation using task #1, I get no errors whatsoever and all images are missing the original changed partitions.
I checked the task settings/specs and they are identical. The only difference I can see is task #1 was created under a much older version of HBS (can't tell what version it was running at the time it was created) and task #2 was created under the current version.
Both of these tasks are tracking the current System image... task #1 never errors and always leaves out the (2) originally geometrically changed partitions, task #2 always errors accordingly.
I don't know how deep you want to go chasing this anomaly... I have protected myself, accordingly, using the newer task #2. Sounds like from your description of possible upcoming changes, this will make this whole anomaly moot.
What else would you like me to do...?
Honestly, I can't reproduce the issue you mentioned where backup tasks created by the older version wouldn't prompt 'Specified partition not found' after partition geometry changes. The code that detects partition modifications hasn't been updated for years, but that's no longer relevant as the problem doesn't occur in the latest version. My only question is, are you sure that you didn't re-edit the backup tasks created by the old version after changing the partition geometry?
That task has never been changed. While testing the MicroSloth anomaly (shrinking the OS partition and enlarging the RE partition using the shrink space), I then ran a manual, task-based, FULL image following the geometry change just to insure I had a good chain starting point. After that FULL, when I looked at the image, is when I noticed the two changed partitions missing from the image (and no error during the manual operation)... that's when I bought it up as an anomaly. I still have that task in place for checking purposes while I'm testing.
If you can't reproduce, why don't we write this one off for the time being and move on with your suggested changes. I will comment on them in Post #39 above.