Windows Support Roadmap

[RangerCD]

This issue is a tracker for Windows support development.

---

Todo

Done

• Support Windows local devices Add Windows support #58
• Support network attached devices, such as SMB Add Windows support #58
• Support block attributes in Mount struct (which should be equivalent to "cluster" for Windows) Add Windows support #58
• Recognize Windows Sandbox device as a special device Add Windows support #58
• Support for code pages other than 437(United States) or 65001(UTF-8) [Windows] Fix broken table structure for non-unicode code page #63

[RangerCD]

Network device support added

[RangerCD]

Block(Cluster) attributes added

[RangerCD]

Recognize Windows Sandbox device as a special device

[RangerCD]

Code page support may be unnecessary if #49 solved, I will keep tracking.

[muesli]

Since we're already breaking with old traditions, I'm actually pondering to rename the FILESYSTEM caption with DEVICE. I think that makes more sense on all platforms. Opinions?

[RangerCD]

I'm a little bit concerned about ambiguity. For linux, it's OK since all those filesystems are listed in /dev. But for Windows, DEVICE is more like a physical disk drive, a HDD or SSD that holds multiple filesystems/volumes/partitions, we can only see physical devices in "Device Manager".

[SuperSandro2000]

When I run duf master in WSL some filesystems are wrong or missing:

./duf
╭────────────────────────────────────────────────────────────────────────────────────────────╮
│ 5 local devices                                                                            │
├────────────┬────────┬────────┬────────┬───────────────────────────────┬───────┬────────────┤
│ MOUNTED ON │   SIZE │   USED │  AVAIL │              USE%             │ TYPE  │ FILESYSTEM │
├────────────┼────────┼────────┼────────┼───────────────────────────────┼───────┼────────────┤
│ /          │ 464.7G │ 302.9G │ 161.8G │ [#############.......]  65.2% │ wslfs │ rootfs     │
│ /mnt/c     │ 464.7G │ 302.9G │ 161.8G │ [#############.......]  65.2% │ drvfs │ C:\134     │
│ /mnt/d     │ 465.6G │ 409.9G │  55.7G │ [#################...]  88.0% │ drvfs │ D:\134     │
│ /mnt/e     │ 223.6G │ 111.5G │ 112.0G │ [#########...........]  49.9% │ drvfs │ E:\134     │
│ /mnt/f     │ 465.7G │ 421.2G │  44.6G │ [##################..]  90.4% │ drvfs │ F:\134     │
╰────────────┴────────┴────────┴────────┴───────────────────────────────┴───────┴────────────╯
╭────────────────────────────────────────────────────────────────────────────────────────────────╮
│ 6 special devices                                                                              │
├────────────────┬────────┬────────┬────────┬───────────────────────────────┬───────┬────────────┤
│ MOUNTED ON     │   SIZE │   USED │  AVAIL │              USE%             │ TYPE  │ FILESYSTEM │
├────────────────┼────────┼────────┼────────┼───────────────────────────────┼───────┼────────────┤
│ /dev           │ 464.7G │ 302.9G │ 161.8G │ [#############.......]  65.2% │ tmpfs │ none       │
│ /run           │ 464.7G │ 302.9G │ 161.8G │ [#############.......]  65.2% │ tmpfs │ none       │
│ /run/lock      │ 464.7G │ 302.9G │ 161.8G │ [#############.......]  65.2% │ tmpfs │ none       │
│ /run/shm       │ 464.7G │ 302.9G │ 161.8G │ [#############.......]  65.2% │ tmpfs │ none       │
│ /run/user      │ 464.7G │ 302.9G │ 161.8G │ [#############.......]  65.2% │ tmpfs │ none       │
│ /sys/fs/cgroup │ 464.7G │ 302.9G │ 161.8G │ [#############.......]  65.2% │ tmpfs │ tmpfs      │
╰────────────────┴────────┴────────┴────────┴───────────────────────────────┴───────┴────────────╯

[RangerCD]

Could you please paste the output of df -T inside WSL? duf is supposed to show similar result to df.

[muesli]

@RangerCD #49 has just been resolved and there's now the possibility to switch to a different table style, e.g. ascii. Maybe we should make that the default on Windows?

[RangerCD]

@muesli Nice 😄 I'll try this later. Maybe we could automatically enable ASCII if current code page doesn't support unicode.

[muesli]

Good idea. I'm also curious how table.StyleLight would behave (you'd have to set it manually in parseStyle for a test). Does that still cause issues on Windows?

[muesli]

Just a heads up: with that ticked off, I think I'll release a v0.4.0.

[RangerCD]

@muesli
--style ascii works pretty well for non-unicode code page.
And unfortunately, table.StyleLight has the same issue.
I want to try one more time before finally deciding to use "degrade to ASCII" solution, by temporarily set code page to 65001 and restore before exit.

[RangerCD]

Changing code page might have some unexpected side effect. Have to be carefully tested.

[SuperSandro2000]

Could you please paste the output of df -T inside WSL? duf is supposed to show similar result to df.

 ▶ df -T
Filesystem     Type   Size  Used Avail Use% Mounted on
rootfs         wslfs  465G  311G  155G  67% /
none           tmpfs  465G  311G  155G  67% /dev
none           tmpfs  465G  311G  155G  67% /run
none           tmpfs  465G  311G  155G  67% /run/lock
none           tmpfs  465G  311G  155G  67% /run/shm
none           tmpfs  465G  311G  155G  67% /run/user
tmpfs          tmpfs  465G  311G  155G  67% /sys/fs/cgroup
C:\            drvfs  465G  311G  155G  67% /mnt/c
D:\            drvfs  466G  410G   56G  89% /mnt/d
E:\            drvfs  224G  112G  113G  50% /mnt/e
F:\            drvfs  466G  422G   45G  91% /mnt/f

C:\ is a very strange filesystem name 🤔

[RangerCD]

@SuperSandro2000 That C:\134 in duf output is much more stranger than C:\ in df 🤔

[RangerCD]

@muesli
After deeper research, here is a comprehensive report of code page issue

---

Phenomenon

For some of the non-unicode code page (such as 932 or 936), table could not be rendered correctly:

╭─────────────────────────────────────────────────────────────────────────────────────────────────╮
│ 1 local devices                                                                                 │
├────────────┬────────┬────────┬────────┬───────────────────────────────┬──────┬────────────┤ ≈
│ MOUNTED ON │   SIZE │   USED │  AVAIL │              USE%             │ TYPE │ FILESYSTEM │
├────────────┼────────┼────────┼────────┼───────────────────────────────┼──────┼────────────┤ ≈
│ C:\        │ 475.8G │ 370.6G │ 105.2G │ [###############.....]  77.9% │ NTFS │ System[0]  │
╰────────────┴────────┴────────┴────────┴───────────────────────────────┴──────┴────────────╯ ≈

Reason

The root cause of this issue is that RuneWidth function in github.com/mattn/go-runewidth returns incorrect width of table border characters.
Test case:

package main

import (
	"fmt"
	"github.com/mattn/go-runewidth"
)

const targetRune = '╭'

func main() {
	fmt.Println("Target character:", string(targetRune))
	fmt.Println("Rune width:", runewidth.RuneWidth(targetRune))
}

targetRune is the top left corner character of a table.
Expected result(code page 437):

Target character: ╭
Rune width: 1

Unexpected result(code page 932 or 936):

Target character: ╭
Rune width: 2

But for both expected and unexpected case, this character only takes a single halfwidth letter space on screen:

RuneWidth function is called in github.com/jedib0t/go-pretty to calculate row length, incorrect rune width leads to incorrect row length.

Solution

On Windows platform, use ascii as style by default if runewidth.RuneWidth('╭') > 1, as #63 does.

[SuperSandro2000]

Does WSL use code pages? I am not running it in command line. I tested this in WSL with Jetbrains Mono font.

[RangerCD]

@SuperSandro2000 WSL is another story. I suggest to start another issue about that C:\134 problem.