polybar: Filesystem module displaying incorrect values
Hello,
For some reason the filesystem module of polybar is showing that the ‘/’ mount has a total size of 1.97GB and current used space of 851MB. This is with the default config (other than adding tags to display the total and used values). On the other hand, here is the output of df -h for that mountpoint:
/dev/dm-0 158G 8.9G 142G 6% /
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 28 (13 by maintainers)
Commits related to this issue
- fix(fs): Calculate free bytes properly Seems this was missed in a682d2af91881fa775e265520f7f820cb71dc707 This is now also consistent with what df does Closes #743 — committed to patrick96/polybar by patrick96 5 years ago
- fix(fs): Calculate free bytes properly Seems this was missed in a682d2af91881fa775e265520f7f820cb71dc707 This is now also consistent with what df does Closes #743 — committed to polybar/polybar by patrick96 5 years ago
- fs: Fix incorrect size report on 32bit machines Cast before calculate to avoid overflow. Fixes #743 — committed to notok/polybar by notok 5 years ago
- fs: Fix incorrect size report on 32bit machines (#1699) Cast before multiplication to avoid overflow. Fixes #743 — committed to polybar/polybar by notok 5 years ago
- fix(fs): Calculate free bytes properly Seems this was missed in a682d2af91881fa775e265520f7f820cb71dc707 This is now also consistent with what df does Closes #743 — committed to polybar/polybar by patrick96 5 years ago
- fs: Fix incorrect size report on 32bit machines (#1699) Cast before multiplication to avoid overflow. Fixes #743 — committed to polybar/polybar by notok 5 years ago
- Release 3.3.1 Changelog Fixes: * `internal/xworkspaces`: * Crash when WM doesn't set `_NET_DESKTOP_NAMES` (#1576), see #1462 * Workspace removal not always detected (#1579), see #1491, #248 ... — committed to polybar/polybar by patrick96 5 years ago
- Release 3.3.1 Changelog Fixes: * `internal/xworkspaces`: * Crash when WM doesn't set `_NET_DESKTOP_NAMES` (#1576), see #1462 * Workspace removal not always detected (#1579), see #1491, #248 ... — committed to polybar/polybar by patrick96 5 years ago
- Release 3.3.1 Changelog Fixes: * `internal/xworkspaces`: * Crash when WM doesn't set `_NET_DESKTOP_NAMES` (#1576), see #1462 * Workspace removal not always detected (#1579), see #1491, #248 ... — committed to doronbehar/polybar by patrick96 5 years ago
- Release 3.3.1 Changelog Fixes: * `internal/xworkspaces`: * Crash when WM doesn't set `_NET_DESKTOP_NAMES` (#1576), see #1462 * Workspace removal not always detected (#1579), see #1491, #248 ... — committed to doronbehar/polybar by patrick96 5 years ago
- Release 3.3.1 Changelog Fixes: * `internal/xworkspaces`: * Crash when WM doesn't set `_NET_DESKTOP_NAMES` (#1576), see #1462 * Workspace removal not always detected (#1579), see #1491, #248 ... — committed to doronbehar/polybar by patrick96 5 years ago
- Release 3.3.1 Changelog Fixes: * `internal/xworkspaces`: * Crash when WM doesn't set `_NET_DESKTOP_NAMES` (#1576), see #1462 * Workspace removal not always detected (#1579), see #1491, #248 ... — committed to doronbehar/polybar by patrick96 5 years ago
You don’t need both packages, there were no changes to the filesystem module between
polybarandpolybar-gitThis output for
freelooks weird, you have as much free space as is usedBoth at the same time preferably. When you compile multiple times without each time clearing everything it should only compile the changed files, which should be a lot faster, if that works, it would be interesting to see the effects of only the second modification.
Also, can you then report the values for all three tokens (
label-mounted = %total% %free% %used%)Oh damn. I appreciate you helping use here 😃
Were you able to figure out where polybar does a wrong calculation?
Could you also try to change this line to
and try if it displays the correct values?
The crash was unrelated to polybar hopefully?
We use the
statvfsfunction (man 3 statvfs) to gather information about mounted filesystems (all the code for it is here).I see that we are using
f_frsizefor some properties andf_bsizefor others. Maybe that’s the issue. I suspect the integer underflow happens on line 102:Just noticed,
16777216.00 TBconverted to bytes is exactly2^64. So we likely have some integer underflow/overflow or signed/unsigned weirdness.