os.path.ismount

Every few months someone's training or batch-render job dies halfway because the external drive unmounted, the NAS went to sleep, or a network share dropped - and by the time the workflow tried to write, the path was a dangling mount point. os.path.ismount tells you whether a given path is a mount point: the top of a filesystem, where a drive, partition, or network share was attached.

It's part of the ovum/path/os.path family in comfy-ovum, sfinktah's utility pack, and it's a direct wrapper over Python's os.path.ismount(). As always in this family: stdlib behavior, nothing invented.

How it works

Predicate, returns a BOOLEAN (ismount). Path from:

• path (STRING, required): the widget.
• path_in (PATHLIKE,STRING, optional): link-only; overrides the widget when connected.

On Unix it checks whether the path is the root of a mounted filesystem (including bind mounts). It's safe on odd input - non-existent paths return False rather than raising. One BOOLEAN out.

Why you'd reach for it

The honest answer: this is the most niche node in the path family. It earns its place in one scenario - pre-flight checks for workflows that read or write external storage. If your outputs live on a second SSD or a network share, run the output root through ismount (or check that the path exists with os.path.isdir) before the expensive render, and fail with a clear message if the mount is gone. That converts "job died at minute 40" into "job refused to start because the drive isn't mounted," which is strictly better.

It's also the correct way to walk a filesystem tree and find boundaries - if you ever build a graph that recurses directories, ismount is how you avoid walking up past the root of a mounted drive into the parent filesystem.

Installing it

Standard, once per pack:

cd ComfyUI/custom_nodes
git clone https://github.com/sfinktah/comfy-ovum

Or ComfyUI Manager → "comfy-ovum" → Install → restart. No models, no extra deps.

Platform reality check

On Windows this node is effectively a stub - it returns True only for drive roots like C:\, not for network-mapped shares or mounted volumes, because the stdlib's Windows implementation is that thin. So if you're on Windows and hoping to detect a dropped Z: share, this node won't be your hero; a simpler "does the path exist" check via isdir will behave better. On Linux and macOS, where external drives and NFS/SMB mounts are the norm, ismount is accurate and genuinely useful.

If you're building cross-platform workflows, don't gate critical logic on ismount alone - combine it with an existence check, since a mounted-but-empty path and an unmounted path can both fail your pipeline in different ways. It's a diagnostic first, a guard second.