Hmbown/CodeWhale · error
Refusing a non-regular settings lock at {}
Error message
Refusing a non-regular settings lock at {} What it means
Settings lock hardening: the opened lock file's metadata shows it is not a regular file (e.g. a fifo or device planted at settings.toml.lock). Locking through such a node could block or be manipulated, so the code refuses and names the offending path.
Source
Thrown at crates/tui/src/settings.rs:2149
let lock_file = options
.open(&lock_path)
.with_context(|| format!("Failed to open settings lock at {}", lock_path.display()))?;
#[cfg(unix)]
{
use std::os::unix::fs::PermissionsExt as _;
lock_file
.set_permissions(fs::Permissions::from_mode(0o600))
.with_context(|| {
format!("Failed to secure settings lock at {}", lock_path.display())
})?;
}
if !lock_file
.metadata()
.with_context(|| format!("Failed to inspect settings lock at {}", lock_path.display()))?
.file_type()
.is_file()
{
anyhow::bail!(
"Refusing a non-regular settings lock at {}",
lock_path.display()
);
}
let mut lock = fd_lock::RwLock::new(lock_file);
let _guard = lock
.write()
.with_context(|| format!("Failed to acquire settings lock at {}", lock_path.display()))?;
operation()
}
/// Refuse to lock through a symlink: a planted `settings.toml.lock -> …` would
/// otherwise let an attacker pick which file we create with our permissions.
fn reject_settings_lock_symlink(lock_path: &Path) -> Result<()> {
match std::fs::symlink_metadata(lock_path) {
Ok(metadata) if metadata.file_type().is_symlink() => anyhow::bail!(
"Refusing a symlinked settings lock at {}",View on GitHub (pinned to 0c42157ee5)
Solutions
- Delete the non-regular settings.toml.lock
- Retry the settings operation
Defensive patterns
Strategy: type-guard
When it happens
Trigger: Thrown at crates/tui/src/settings.rs:2149 when the library encounters an invalid state.
Common situations: See trigger scenarios.
AI-assisted analysis of Hmbown/CodeWhale@0c42157ee5 (2026-08-20).
Data as JSON: /api/errors/ea13a17f4a9543a8.
Report an issue: GitHub.