Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fixes calculation of largest partition byte size
Ensures the byte offset of the final partition being backed up is correctly calculated instead of the current situation where the variable contains a memory address. The calculation fix prevents a sanity check from being incorrectly triggered during a comparison operation with the disk length approximately 32MB or less (depends on exact memory addresses) Also fixes the sfdisk fields parsing (the 'Id' field has been renamed 'type') and ensures the byte offset to the end partition is correctly used, so that the .size file contains the offset to the end of the final partition. This ensures the ability to restore a subset of partitions to a smaller drive, as was intended by [1] but never realized in Rescuezilla until now. Further background: The largest partition byte size calculation feature was added during the development of v1.0.5 (by cherry-picking a git commit authored in 2012 a separate Redo repository in 2012 [1]). During testing at the time, an 'Experimental values on scalar is now forbidden' would pop up, but without sufficient Perl experience at the time, it was unclear that root cause was the values() function no longer being able to operate on hash references, so this issue was "fixed" by removing the values() function altogether, not realizing this would mean the $ptab_bytes variable ends up with a hash reference instead of the largest partition size. This incorrect $ptab_bytes value gets compared to the length of the disk (from blockdev), and the application has a sanity check which exits if it's smaller than the disk length. There has been no reports of application exiting due to this issue (though it may have happened to some people). Because Rescuezilla v1.0.5/v1.0.5.1 use 32-bit memory addresses, the typical length required to trigger this issue is ~32MB or less, but it could potentially trigger on larger disks if the memory address happened to be larger. The proper fix is to dereference the hashref before running the values() function as intended. Task rescuezilla#55 contains more information. [1] 292e1d6 [2] c00448e [3] https://perldoc.perl.org/functions/values.html Fixes rescuezilla#55
- Loading branch information