[BUG] fastfetch on Windows hangs for a long time when calculating the drive size. On WSL, it is instant.

[RioNight]

General description of bug:

• What happened: fastfetch on Windows hangs for a long time before outputting the drive information. Subsequent fastfetch runs are quicker, but after some time, it gets slower again. On WSL, fastfetch is much faster and ouputs all the drive information normally.
• What should happen: It should be quicker.
• Fastfetch version used: fastfetch 2.10.2 (x86_64)
• Did it work in an older version: no
• Where did you get the binary: scoop
• Does this issue still occurs in the latest dev build?

Often helpful information:

Screenshot: It hangs here for a while:

The content of the configuration file you use (if any): (none)

Output of fastfetch -c ci.jsonc --format json:

//paste here

Output of fastfetch --list-features:

threads
vulkan
zlib
opencl
Proprietary GPU driver API

If fastfatch crashed or freezed

Paste the stacktrace here. You may get it with:

# You may need Ctrl+C to stop the process if it freezes
gdb -q -ex 'set confirm off' -ex run -ex 'bt full' -ex quit --args /path/to/fastfetch

If you are able to identify which module crashed, the strace can be helpful too

strace /path/to/fastfetch --multithreading false -s {MODULE} --pipe

If you cannot do the instructions above, please upload the core dump file:

If my image logo didn't show / work

• The image protocol you used:
• The terminal you used: Wezterm
• Upload the image file here, or paste the image URL:
• Does it work with --logo-width {WIDTH} --logo-height {HEIGHT}?

If fastfetch behaves incorrectly on shell starting

• The bug is reproduceable with fresh / clean shell configuration (i.e. fastfetch is the single line of .zshrc or ~/.config/fish/config.fish):
• Does sleep 1 before running fastfetch work?

[RioNight]

I observe this on several Windows machines.

[CarterLi]

Do you have some USB flash drives or portable hard drives plugged in? If yes, plug them out and try again.

[CarterLi]

What does fastfetch -s physicaldisk print?

[CarterLi]

Does diskmgmt.msc hang too?

[RioNight]

To clarify, "a long time" means about 7 seconds. diskmgmt.msc runs but is a bit slow. It does not show network drives. fastfetch -s physicaldisk is instant, but it does not show network drives. WSL doesn't show these network drives as well.

Maybe that's what's causing the hold up. Is there a way to speed this up or leave network drives out of the fastfetch output?

fastfetch -s physicaldisk output:

Physical Disk (HGST HTS721010A9E630): 931.51 GiB [HDD, Fixed]
Physical Disk (Msft Virtual Disk): 8.00 GiB [SSD, Fixed]
Physical Disk (SAMSUNG MZVLW512HMJP-000H1): 476.94 GiB [SSD, Fixed]

[CarterLi]

https://github.com/fastfetch-cli/fastfetch/actions/runs/8881325802/artifacts/1457223656

Try this one with --disk-ignore-remote

[RioNight]

Thanks, this flag works and fastfetch completes instantly. Currently, the default fastfetch takes longer to run than the other default *fetch programs (like winfetch) if there is a network drive. Would you consider setting this to true by default on Windows? Or if there is some other solution to make the default fastfetch run fast on Windows...

[CarterLi]

Currently, the default fastfetch takes longer to run than the other default *fetch programs (like winfetch) if there is a network drive.

It's because winfetch only detects C: by default. If you set $ShowDisks = @("*") winfetch hangs too.

Would you consider setting this to true by default on Windows? Or if there is some other solution to make the default fastfetch run fast on Windows...

No. Network drives are commonly used in VM which match paths in host machine. Accessing them won't block. I don't think many people really mapping network location to local drives.

[CarterLi]

I decided removing --disk-ignore-remote. Instead, use --disk-folders to set which folders you want to detect, which matches behavior of @ShowDisks in winfetch. Default to all unlike winfetch, however.

See fastfetch -h disk-folders for detail

[RioNight]

If you wanted to test network drives without an extra computer, you could connect a USB stick to you router. That is how mine is set up.

[ykhan21]

@CarterLi, I had a similar issue. The network drives appeared to hang fastfetch for 10 seconds. I had two network drives, one connected and one disconnected. Once I told Windows File Explorer to "forget" only the disconnected network drive, it ran fast. It seems like there is a large timeout on getting the network drive information.

[CarterLi]

@ykhan21 Just use --disk-folders C:\

[CarterLi]

It seems like there is a large timeout on getting the network drive information

Windows kernel desides the timeout, and provides no configuration for fastfetch to control it.

[CarterLi]

I investigated it a little bit more. It seems that using sub-threads is the only option ( IO operations stuck at CreateFileW ).

Did a quick fix. Please have a test: https://github.com/fastfetch-cli/fastfetch/actions/runs/8948869450/artifacts/1472816825

[ykhan21]

I tried the latest release. It works now. Thanks.