Skip to content

fix: correct byte conversion factors off by power of 10 in _parse_numbers()#69186

Open
algojogacor wants to merge 1 commit into
saltstack:masterfrom
algojogacor:fix/byte-conversion-factors
Open

fix: correct byte conversion factors off by power of 10 in _parse_numbers()#69186
algojogacor wants to merge 1 commit into
saltstack:masterfrom
algojogacor:fix/byte-conversion-factors

Conversation

@algojogacor
Copy link
Copy Markdown

This is an independent contribution. The author has no affiliation with the project maintainers.

Summary

Fixed byte conversion factors in _parse_numbers() where all unit suffixes were off by a factor of 10, causing incorrect size parsing. For example, "1.0K" was being parsed as 10000.0 instead of the correct 1000.0.

Root Cause

The postPrefixes dictionary in salt/modules/disk.py used 10E3, 10E6, etc. as multiplier values instead of 1E3, 1E6. In Python's scientific notation, 10E3 = 10 × 10³ = 10,000 while 1E3 = 1 × 10³ = 1,000. Since the prefix multipliers (K=10³, M=10⁶, G=10⁹, etc.) should represent single-base-unit multiples, the 1E prefix is correct.

Fix

Changed all eight entries in the postPrefixes dictionary from 10E to 1E prefix:

K: 10E3 → 1E3
M: 10E6 → 1E6
G: 10E9 → 1E9
T: 10E12 → 1E12
P: 10E15 → 1E15
E: 10E18 → 1E18
Z: 10E21 → 1E21
Y: 10E24 → 1E24

Testing

Verified with the Python interpreter:

Before: float(_parse_numbers("1.0K"))10000.0
After: float(_parse_numbers("1.0K"))1000.0

Closes: #65490

@algojogacor algojogacor requested a review from a team as a code owner May 18, 2026 23:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Byte conversion factors off by power of 10 in _parse_numbers() in modules/disk.py

1 participant