Expand description
The live sessions, and how a container is matched against them. Concept 8: a container that already has a live session is not opened twice, because two sessions on one container would both repack it and the second write-back would overwrite the first with nothing said.
§Neither key is enough on its own
§8 says to key on file identity rather than on a path, and gives the reason: a container reachable under two hard links is two paths and one file, and a canonical path cannot see that.
What §8 does not account for — found while writing identity.rs — is that
write-back replaces the container by renaming a new file over it, so a
container acquires a new inode every time a session saves. An identity
recorded when the session opened stops matching the file at that path after
the first write-back, and the next invocation of the same container would
find no entry and open the second session that all of this exists to
prevent.
So a lookup matches on either. The path is stable across replacement and blind to hard links; the identity is the opposite. Together they cover both, and the case where they disagree is handled correctly rather than by accident: after a write-back through one of two hard links, §7 says the other name still points at the original with the old contents, so the two really are different files by then — different path, different identity, no match, and a new session, which is right.
Structs§
- Table
- The sessions this instance is holding.