| Previous | Next |
| EEXIST | ENODEV |
EXDEV
Why a “move” can fail
EXDEV is most commonly seen when code assumes that a rename is a universal move operation. A filesystem rename changes directory entries within one mounted filesystem; it is not a copy engine. When source and destination are on different mounts, a direct rename cannot preserve the usual atomic rename semantics and the kernel returns EXDEV.
Hard links have the same boundary: both directory entries must refer to the same underlying filesystem object. Even two mount paths that appear related can behave as different mounts for these operations. The error does not mean that either path is invalid or inaccessible.
Safe handling
- Detect cross-filesystem moves before relying on rename for an atomic publish or replacement workflow.
- Use a copy-or-stream operation to create the destination, verify the result, then remove the source only after successful completion.
- Preserve metadata and durability requirements explicitly; a cross-filesystem fallback is not automatically atomic.
- For hard-link intent, use a symbolic link or redesign storage placement when links must span filesystem boundaries.
References
Looking for a different code? Search another status or error code.