`io::Error` can be `ErrorKind::Uncategorized` when a network filesystem has gone away

Context

When calling std::fs::metadata on a path originating as a Thumb::URI field (path of original image) from an XDG-specified thumbnail to check for staleness, I wound up with an uncategorized error with raw OS error number 5.

It turned out to be an XDG Documents Portal path (/run/user/1000/doc/ceb0a8fc/me.png) that flatpak documents --columns=id,origin | grep ceb0a8fc showed to map to a KIO FUSE path (/run/user/1000/kio-fuse-yHXkJj/sftp/[...]) pointing at a machine which was powered off at least a week ago but which hadn't been retired by KIO FUSE for some reason.

Result

std::fs::metadata reported ErrorKind::Uncategorized with .raw_os_error() being Some(5) and I confirmed this is proxied up from the underlying KIO FUSE path with a quick os.stat in the Python REPL. (OSError: [Errno 5] Input/output error)

It turns out this is the error code for "timeout trying to contact the server"... at least, according to my reproducer using sshfs.

I also reproduced using mount.cifs and got another ErrorKind::Uncategorized... though, this time, it was Os { code: 112, kind: Uncategorized, message: "Host is down" })

Reproducer

NOTE: This will require two machines, one of which you can physically unplug from your LAN so the server doesn't have the chance to warn the client that it's going away.

1. Mount a network filesystem using sshfs -o ServerAliveInterval=5 (I don't know how to reproduce with KIO SFTP)
2. Physically unplug the network cable so the machine serving up the network share doesn't have an opportunity to warn the client that it's going away.
3. Less than 5 seconds later, attempt to std::fs::metadata a path within the network filesystem that hasn't already had its metadata cached by a previous request.
4. Wait for the timeout

Result: Err(Os { code: 5, kind: Uncategorized, message: "Input/output error" })

Note that, even if you do wait through KIO SFTP's default 15-20 minute timeout, applying these instructions to it will still return ErrorKind::NotFound. I'm not sure how to get it back into the state I initially observed where it was returning error 5 without waiting for a timeout, so sshfs reproducer it is.

To reproduce the code 112 (Host is down), replace sshfs with mount -t cifs and follow the same instructions.

(Since I was using my Windows XP retro-laptop as the server, I had to grant permission to a non-Administrator account at both the filesystem and network share level and then use sudo mount -t cifs -o username=foo,vers=1.0 //192.168.0.33/Test ~/mnt/tmp to mount.)

I don't currently have anything set up to serve NFS, so I can't test what error code that'll return, and davfs2 seems to do things like anticipatory caching and serving potentially stale stat info after a timeout, so I'd have to rewrite my little Rust test stub to determine what ErrorKind opening files on a gone-away network share produces, but Python says it returns [Errno 11] Resource temporarily unavailable.

Meta

rustc --version --verbose:

rustc 1.93.0-nightly (adaa83897 2025-10-27)
binary: rustc
commit-hash: adaa838976ff99a4f0661136322f64cb466b58a0
commit-date: 2025-10-27
host: x86_64-unknown-linux-gnu
release: 1.93.0-nightly
LLVM version: 21.1.3

lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.3 LTS
Release:        24.04
Codename:       noble

Start with std::fs::metadata and the conversion of OS errors into ErrorKind, then reproduce the reported failures with sshfs or mount.cifs after disconnecting the server. Done should include a decided and tested classification for the relevant network-filesystem errors instead of ErrorKind::Uncategorized.