cap-std panic's when WASM module is listing C:

[elast0ny]

When running a simple Rust directory listing module on my C:\ drive as a test, cap-std will throw a panic :
'ino' depends on a Metadata constructed from an open 'File'

This can be reproduced through wasmtime with :
wasmtime run --dir C:\ list_dir.wasm -- C:\

This older issue #142 seems to be the same problem although it was closed with claims that it had been fixed ?
Did the bug get re-introduced somehow ?

I unfortunately don't have access to my list_dir project but its essentially only std::fs::read_dir(argv[1])

The important parts in my panic backtrace are :

wasmtime 0.26.0
    wasi-common 0.26.0    (wasi_common::snapshots::preview_1::wasi_snapshot_preview1::fd_readdir)
        wasi-cap-std-sync 0.26.0    (wasi_cap_std_sync::dir::{{impl}}::readdir)
            cap-fs-ext 0.13.9   (cap_fs_ext::metadata_ext::{{impl}}::ino)

[elast0ny]

It seems like my Windows 10 install contains some hidden system files which trip up cap-std. For example, when listing :

• C:\DumpStack.log.tmp
• C:\Windows\ccmcache
• C:\Windows\System32\config

[sunfishcode]

I can reproduce this, and C:\DumpStack.log.tmp is the file cap-std is failing on on my Windows box. WASI's read_dir expects to be able to get an "inode" (file index) for all directory entries, but all methods I know of for obtaining the Windows file index are failing on DumpStack.log.tmp. So this is a different underlying problem than #142.

Should we skip over those files as if they aren't there? Or should we make up bogus number_of_links and file_index numbers for them? Or is there another way to get this information?

Another option would be to change WASI to not require and inode number, though that would be a regression in POSIX-like functionality.

[sunfishcode]

This is fixed by bytecodealliance/wasmtime#2884 and #171.