Documentation
¶
Overview ¶
Package configdir resolves the on-disk location for kojo's configuration directory.
Starting with v1, kojo uses a major-version-suffixed directory name so that breaking storage changes can ship without touching the previous-major data in place. The v0 directory remains read-only from v1 binaries; v1 reads it during the one-shot import (`internal/migrate`) and afterwards only in narrow runtime fallback paths (e.g. session reattach via the v0 `sessions.json` so live tmux panes from a v0 daemon stay reachable — gated on `v1Complete && v0Exists` in `cmd/kojo/main.go`). Boot does NOT re-walk the v0 manifest: once `migration_complete.json` exists v1 is canonical and v0 is a rollback snapshot — divergence is the operator's problem to resolve, not a boot blocker (a missing v0 dir post-cleanup is also the expected steady state). The manifest comparison still happens, but only inside `kojo --clean v0` (cmd/kojo/clean_v0.go), which refuses to soft-delete a diverged v0 dir without `--clean-force`. See docs §5.8 / §5.9 for the safety gates and the still-deferred sub-targets (--keep-blobs, --hard-delete, --purge-trash, 7-day auto-sweep).
Path resolution (no override):
macOS: ~/.config/kojo-v1/ (v1) ; ~/.config/kojo/ (v0) Linux (XDG_CONFIG_HOME=$X): $X/kojo-v1/ (v1) ; $X/kojo/ (v0) Linux (XDG unset): ~/.config/kojo-v1/ (v1) ; ~/.config/kojo/ (v0) Windows: %APPDATA%\kojo-v1\ (v1) ; %APPDATA%\kojo\ (v0)
`kojo` (the bare name) is permanently the v0 path. Future v2 will use `kojo-v2`. Never collapse the suffix back to the bare name; doing so would silently overwrite v0 data.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Path ¶
func Path() string
Path returns the v1 configuration directory.
- If Set() was called, that path
- Otherwise the platform default for the current major version (v1)
func Probe ¶ added in v0.101.0
Probe reports whether another process currently holds the kojo.lock file inside `dir`. Unlike Acquire, Probe is non-destructive:
- it never creates the lock file (returns held=false on ENOENT)
- it opens the file O_RDONLY so the v0 dir is never opened for write
- it never updates the file's mtime / inode
- if it manages to grab the advisory lock, it releases it before returning so the holder's view is unchanged
This is the only safe way to ask "is v0 currently running?" from the v1 migration code path; Acquire would clobber the lock file's metadata and could even create one inside an empty v0 dir.
func Set ¶ added in v0.11.0
func Set(path string)
Set overrides the v1 config directory path. Must be called at most once, before any subsystem accesses Path(). Subsequent calls are ignored so the resolved directory cannot change under a running process.
Set does NOT affect V0Path(); v0 path resolution always follows the platform defaults so migration tooling cannot be redirected away from real user data by an accidental --config-dir flag.
func V0Path ¶ added in v0.101.0
func V0Path() string
V0Path returns the v0 configuration directory (the legacy `kojo` dir), honoring XDG_CONFIG_HOME / APPDATA the same way v0 itself did. This is the only entry point migration tooling (and the v0-dir cleanup target landed in slice 29) should use to locate v0 data.
V0Path is unaffected by Set(): v0 layout is fixed by history.
Types ¶
type Lock ¶ added in v0.11.0
type Lock struct {
// contains filtered or unexported fields
}
Lock holds an exclusive advisory lock on a kojo config directory. The lock is released by the kernel when the holding process exits (including on crash) or when Release is called explicitly.
Source Files