In pathlib, how does Path.resolve() differ from Path.absolute(), and how do you check a path stays under a base directory?

These two calls look interchangeable and are not: one is string algebra with the working directory bolted on, the other is a filesystem operation. ### absolute() versus resolve() `Path.absolute()` returns the path joined to `Path.cwd()` if it is relative, and otherwise returns it unchanged. It performs no normalisation whatsoever: `Path("exports/a/../b").absolute()` still has `'..'` sitting in its `.parts`, and a symlink in the middle is still a symlink. It is cheap and it never fails on a missing file. `Path.resolve()` does three things: makes the path absolute, follows every symlink encountered along it, and eliminates `..` components. It is the only pathlib method that removes `..`, and the order matters enormously — `a/link/..` is not `a` when `link` points somewhere else, so any purely lexical collapse of `..` can produce a path that names a different file than the one the operating system would reach. `resolve()` gets that right because it asks the filesystem; a symlink cycle surfaces as an `OSError`. Since Python 3.6 `resolve()` is non-strict by default, which is what makes it usable on a path you are about to create: missing trailing components are simply carried through. `resolve(strict=True)` raises `OSError` — concretely a `FileNotFoundError` — when the path does not exist, which is the right choice when you are validating something that is supposed to be there already. The `os.path` mapping is worth holding in your head, because the naming is a trap: `os.path.abspath` is **not** `resolve()`. `abspath` is `normpath(join(getcwd(), p))`, and `normpath` collapses `..` lexically without consulting the filesystem — so it is `absolute()` plus a lexical squash, and it can lie in the presence of symlinks. The true analogue of `resolve()` is `os.path.realpath`. Neither expands `~`; that is `Path.expanduser()`, and `resolve()` will not do it for you. ### Establishing containment The question "is this path inside that directory?" comes up whenever a path component arrives from outside the process — a request parameter, a config entry, an archive member name. Two facts make the naive version wrong. First, joining does not confine: `Path("/srv/exports") / "../../etc/hosts"` is a path that reaches outside, and an absolute segment discards the base entirely. Second, `is_relative_to()` — added in 3.9 — is a **lexical** comparison of components; it does not resolve anything, so asking it about an unnormalised candidate answers the wrong question. The sound shape is therefore: resolve the base once, join the untrusted segment, resolve the candidate, and only then compare. ```python base = Path("/srv/exports").resolve() candidate = (base / user_segment).resolve() if not candidate.is_relative_to(base): raise ValueError("outside base") ``` `relative_to()` inside a `try/except ValueError` is the pre-3.9 spelling of the same test and additionally hands you the relative remainder. Note that 3.12 added `relative_to(walk_up=True)`, which permits `..` in the *result*; that is for computing a relative link between two known paths, and it is precisely what you do not want in a containment check. ### What the check still does not give you Resolving and comparing is a decision made at one instant; opening the file happens at another. Between those two moments a component of the path can be replaced with a symlink pointing elsewhere, and your resolved answer is stale. That check-then-use window is inherent to any path-based validation. Narrowing it means holding a descriptor rather than re-deriving a name — opening the directory once and working relative to it via the `os` module's `dir_fd` support, or opening with `os.O_NOFOLLOW` — and structurally, not accepting a path segment at all: take an identifier and look the filename up yourself. The security taxonomy around this belongs elsewhere; what matters here is that `resolve()` normalises, it does not lock. Two smaller points round it out. `Path.samefile()` answers "same file?" by comparing stat results rather than strings, which is the honest test when both paths already exist. And `Path.exists()` gained `follow_symlinks=` in 3.12, so you can ask about a dangling symlink itself instead of its unreachable target.