Improve DirectStorage fallback and CUDA runtime discovery

[chinazhangchao]

This pull request improves the handling of DirectStorage and CUDA runtime library discovery, especially for Windows environments and framework-bundled runtimes (such as PyTorch). It adds robust fallback mechanisms, better error handling, and framework-aware runtime selection. The changes also introduce new tests covering these scenarios.

DirectStorage fallback and error handling:

• The DirectStorage copier (dstorage) now falls back to the nogds copier if the required DLLs are not installed and emits a warning only once. However, if an explicit DLL directory is set but invalid, it raises an error instead of falling back. [1] [2] [3]
• Introduced the custom exception DirectStorageUnavailableError to distinguish between missing DLLs and explicit misconfiguration. [1] [2]

CUDA runtime library discovery improvements:

• The CUDA runtime discovery on Windows now checks framework-provided runtime directories (e.g., PyTorch's torch\lib) before falling back to system locations, and an explicit environment variable always takes precedence. [1] [2] [3] [4]
• Frameworks can now provide a get_runtime_lib_dirs method to supply trusted directories for bundled GPU runtimes. This is implemented for PyTorch. [1] [2] [3]

Documentation updates:

• The overview documentation now clearly describes the DirectStorage fallback behavior and the environment variables for configuration.

Expanded test coverage:

• Added tests to verify that the DirectStorage fallback and error handling work as intended, and that CUDA runtime discovery prefers framework-bundled DLLs or explicit overrides. [1] [2] [3]

[chinazhangchao]

Hi @takeshi-yoshimura, could you please help to review? We’re seeing this issue when using fastsafetensors on Windows.

[gitbisector]

While we're here: both version selections sort lexicographically, so a two-digit major loses to a one-digit one — on this branch a directory holding cudart64_9.dll and cudart64_12.dll resolves to the 9, and with CUDA v9.0 and v12.6 both installed the Program Files scan picks v9.0/bin/cudart64_9.dll.

It predates this PR so entirely your call, but you're editing the glob directly above matches.sort(reverse=True) and get_runtime_lib_dirs adds a new caller of _find_cudart_in_dir — sorting on a parsed integer key (int(re.search(r"cudart64_(\d+)", name).group(1)), and the same idea for the vNN.N directory listing) fixes both.

[takeshi-yoshimura]

@chinazhangchao generally looks good (and good catch @gitbisector). could you please fix some exceptional cases as I commented?

[takeshi-yoshimura]

Merged. thanks.