Question: Should model downloads support exFAT filesystems?

[JunDengH]

Question

Does Comfy Desktop intend to support model directories on exFAT/FAT32 filesystems? If so, what finalization strategy would maintainers prefer when hard links are unavailable?

Context

• Comfy Desktop: 1.0.46
• OS: Windows 11
• Model root: an E: drive formatted as exFAT
• Download source: the in-app managed model downloader

The model download reaches its expected byte count, but the final step fails with:

Failed to move download to final location

The complete staged file and sidecar remain in the correct model directory:

<model>.safetensors.part
<model>.safetensors.part.dl-meta

For one reproduced download, the .part size was exactly equal to the sidecar's expectedSize (1,956,193,000 bytes), the final path did not exist, and the drive had ample free space and writable permissions.

What appears to happen

installStagedAtFinal() first calls fs.linkSync(stagingPath, finalPath). Hard links are not supported by exFAT. A direct test using the current repository code on the real exFAT volume produced:

EISDIR: illegal operation on a directory, link '<model>.safetensors.part' -> '<model>.safetensors'

This is notable because LINK_UNSUPPORTED_CODES anticipates EPERM for Windows exFAT/FAT32, but this Node/libuv combination reports EISDIR. Even for recognized capability errors, installStagedAtFinal() currently throws atomic no-replace install is not supported by this filesystem and retains the staged bytes.

Reproduction

1. Configure modelsDirs on an exFAT volume.
2. Start a model download from a built-in template/missing-model dialog.
3. Wait until the progress reaches 100%.
4. Observe that the .part file matches expectedSize, but finalization fails and no final model file is created.

Questions for maintainers

1. Is storing Desktop model directories on exFAT/FAT32 intentionally unsupported?
2. If these filesystems should be supported, would an exclusive wx claim followed by same-directory rename be an acceptable fallback for known hard-link capability errors? Startup scanning already contains recovery handling for a crashed zero-byte claim marker.
3. If the no-clobber guarantees make that fallback unacceptable, should Desktop detect unsupported filesystems before downloading and show a clear validation error instead of downloading the entire model first?

This may also explain the EISDIR finalization error reported in #1450; the error can occur on exFAT even when both the staging and final paths include the correct category and filename.