Closed pverscha closed 2 years ago
Apparently this issue is caused by different versions of the df
-command that can be installed on systems (and that are being used by the application under the hood). macOS
for example provides a very old version of df
by default which does not support the B
-parameter. I have a more recent version of df
(more specifically, the GNU version) installed on my local system which is apparently used by the application in "debug" mode, but not in "release" mode (causing the weird behaviour).
I have already changed the frequency by which the disk space is polled to once every 30s (instead of once every second) and the application only waits for 200ms before the disk space calculation process is considered failed). This is not a long-term solution however, and we should improve this.
Since we updated all the dependencies of the application, we might be able to use some of the NPM packages that compute disk space (that did not work before because of import issues).
A fix for this issue is provided in #216.
In some situations, it takes a very long time to compute the disk space of the main disk drive of the user. In some cases, the computations even fail after a few seconds (while also blocking the main thread for too long). This behaviour has been observed in the "release" version of the Unipept Desktop app on macOS, but needs to be investigated on other platforms and systems as well. In "debug" mode, everything works well.