sxyazi/yazi · error · io::Error

{e}

Error message

{e}

What it means

This error is produced when converting SFTP protocol `Attrs` permissions (`attrs.perm`, a u32 bitmask) into `ChaMode`: the perm field (defaulted to 0 when absent) is truncated to u16 and passed to `ChaMode::try_from`, which rejects values that don't form a valid Unix mode. The failure is mapped to InvalidData, so it indicates malformed or unsupported permission bits returned by the remote server.

Source

Thrown at yazi-vfs/src/engine/sftp/metadata.rs:70

			mtime: attrs.mtime.and_then(|t| UNIX_EPOCH.checked_add(Duration::from_secs(t as u64))),
			dev: 0,
			uid: attrs.uid.unwrap_or(0),
			gid: attrs.gid.unwrap_or(0),
			nlink: 0,
		}))
	}
}

// --- ChaMode
pub(super) struct ChaMode(pub(super) yazi_fs::cha::ChaMode);

impl TryFrom<&yazi_sftp::fs::Attrs> for ChaMode {
	type Error = io::Error;

	fn try_from(attrs: &yazi_sftp::fs::Attrs) -> Result<Self, Self::Error> {
		yazi_fs::cha::ChaMode::try_from(attrs.perm.unwrap_or_default() as u16)
			.map(Self)
			.map_err(|e| io::Error::new(io::ErrorKind::InvalidData, e))
	}
}

View on GitHub (pinned to 5f901b886b)

Solutions

  1. Check what the remote server reports for permissions (log attrs.perm) and confirm server/protocol compatibility
  2. Update the sftp client/server so modes are reported in standard Unix layout
  3. Sanitize the perm bits before conversion (mask to 0o7777) at the adapter layer if your server emits extra bits
  4. Treat it as server data corruption: re-list the directory or reconnect and retry

Example fix

// before
ChaMode::try_from(attrs.perm.unwrap_or_default() as u16)
// after (mask to valid mode bits first)
ChaMode::try_from((attrs.perm.unwrap_or_default() & 0o7777_777) as u16)
Defensive patterns

Strategy: try-catch

Validate before calling

// Server-provided; can't pre-validate the caller's input, but you can sanity-check after stat
let perm = attrs.perm.unwrap_or_default();
if perm & !0o7777_7777 != 0 { // unexpected high bits
    log::warn!("server returned non-standard perm bits: {perm:#o}");
}

Type guard

fn is_representable_mode(perm: u32) -> bool {
    u16::try_from(perm & 0xffff).is_ok() && yazi_fs::cha::ChaMode::try_from((perm & 0xffff) as u16).is_ok()
}

Try / catch

match Cha::try_from((name, &attrs)) {
    Ok(cha) => cha,
    Err(e) if e.kind() == io::ErrorKind::InvalidData => {
        // permission bits unusable — fall back to a default Cha
        Cha::fallback(name)
    }
    Err(e) => return Err(e),
}

Prevention

When it happens

Trigger: A remote SFTP server returns an `Attrs` whose perm field doesn't fit a valid Unix file-mode layout (extra/high bits beyond the u16 mode space), or omits perm so the defaulted 0/u16 conversion is rejected by ChaMode's validation.

Common situations: Non-Unix or quirky SFTP servers (Windows OpenSSH, some NAS/firmware servers) reporting permission fields differently, protocol-version mismatches producing unexpected flag combos, or servers returning perm=0 for entries without permission support.

Related errors


AI-assisted analysis of sxyazi/yazi@5f901b886b (2026-09-02). Data as JSON: /api/errors/cf2a5ebb16034084. Report an issue: GitHub.