Two Model Paths Can Refer to One Mutable File

Ask whether the second path names another file

An artifact supplier may describe two directories as containing a reference model and a working copy. That description leaves a consequential question open: do the paths select separate files, or are they two names for the same file?

Linux man-pages 6.19 describes a hard link as another name for an existing file. Neither name is inherently the original. The names share the file's ownership and permissions because they refer to one object. Calling one path reference and the other working does not create a private version.

An inode carries file metadata. Its number is unique within its filesystem, rather than across all filesystems. A statement that two paths identify inode 400 therefore needs the filesystem or device context; the bare number cannot establish identity between unrelated storage systems. Here, identity describes the files at the stated observation, not an immutable identifier for their contents.

The example uses existing hard links to ordinary regular files on one local Linux filesystem. It explains completed file-content states, rather than network-client cache behavior or what a running model has already loaded.

References: [H1][I1]

ALIAS72 starts with equal contents but different relationships

Fictional ALIAS72 has one filesystem, F7. Paths A and B are the only two hard links to inode 400. Its contents are represented by [1, 2, 3]. Path C names a separately copied file, inode 401 on F7, whose contents are also [1, 2, 3].

The three integers are unitless teaching values, not a real model format or a byte-capacity specification. C is stipulated to be a separate file with private later writes. There are no concurrent changes, name replacements or other writers in this case. No file operation or model evaluation has been performed.

Initially, reading the represented contents through any of the three paths yields [1, 2, 3]. A content-only comparison at this point cannot distinguish the A/B alias relationship from C's separate identity. Equal values answer what the files contain now; they leave open which paths share a mutable object.

For a buyer, this is the difference between receiving another way to reach the reference artifact and receiving a variant that can diverge from it. The delivery needs to identify which relationship it supplies.

References: [H1][I1]

The in-place edit changes the shared file

At the next stipulated observation, a permitted, completed in-place edit through B has changed inode 400's second value from 2 to 9. It has modified the existing file rather than substituting another file for B. C has received no edit.

A now exposes [1, 9, 3]. B also exposes [1, 9, 3]. C still exposes [1, 2, 3]. There was no copying of the change from B to A: both names select the already changed inode 400. A's name remaining unchanged supplies no reason for its contents to remain [1, 2, 3].

Suppose B's name is subsequently removed, with no further content changes. Inode 400's hard-link count falls from two to one, and A still names it with [1, 9, 3]. Removing B neither reverses the edit nor removes the file still named by A. C continues to name inode 401 with its original values.

This is why the working-copy requirement matters before the edit. If the buyer intended B to be independently editable while A retained the delivered reference values, the initial A/B relationship already failed that requirement. The later edit reveals the consequence of sharing one mutable file; it does not establish a failed synchronization between two copies.

References: [H1][I1][U1]

Distinguish an in-place save from replacing the name

A supplier's statement that an application saves B is incomplete unless it explains the relevant file behavior. Modifying B's existing file has the shared-content consequence in ALIAS72. Successfully replacing B's directory entry with a different file instead changes which object B names. A can continue naming the former file. The rename reference explicitly states that other hard links are unaffected.

That contrast does not prescribe a save method. It explains why every write associated with a path cannot be assumed to modify every former alias. The related pathname-replacement guide owns the separate question of readers that retain an already-open file.

A reflink is different again. The Btrfs project describes separate file metadata referencing shared data blocks. Linux's FICLONE reference requires changes to a shared region to remain private to the file being written on a supporting filesystem. Thus shared backing can coexist with separate editable contents.

Hardlinks share file identity; reflinks can share backing between separate files. A supported reflink may therefore meet a private-edit requirement that an A/B hardlink pair cannot. The related reflink guide covers its eligibility and later allocation growth; no allocation total follows from ALIAS72.

References: [N1][R1][B1]

Choose the artifact relationship the consumer needs

Consider two fictional supply offers for ALIAS72. Offer Shared supplies A and B as aliases of inode 400 and expressly allows an edit through either name to affect the shared artifact. Offer Private supplies a separate working file whose later edits leave the reference file's contents unchanged. These are explanatory offer terms, not Leviathan service commitments.

Shared can be useful when two locations intentionally provide access to one jointly maintained artifact and the buyer accepts that shared mutability. It is insufficient when one location must retain the reference while the other is edited. Private addresses that second requirement if its separate identity and private-write behavior are established for the offered implementation. The distinction concerns content isolation, so it does not by itself require a second full physical copy of every data block.

Ask the appointed artifact or storage supplier to identify what each delivered path names, the filesystem context for that identity, and whether the application's intended saves modify that file or replace its name. Connect those answers to the promised result: may the working artifact change the reference, or must its changes stay private? A list of filenames and equal initial contents leaves that promise unresolved.

Treat retained content, recovery and capacity as additional requirements. A release-like filename does not enforce immutability. Separate C is unchanged in the stipulated edit, but its identity alone establishes neither independent failure protection nor a usable backup. Neither three path names nor two inode identities establishes allocated storage. The useful buying decision is to secure the required edit relationship, then assess those other claims on their own evidence.

References: [H1][I1][R1][B1]

Connect a separate equipment project to physical installation

If the surrounding platform project also requires equipment installation, Leviathan's rack-and-stack service and project inquiry below are relevant to that physical work. Share a nonconfidential equipment summary, site, approved rack positions, IT connection requirements and required installation records to discuss scope and availability.

Artifact supply, filesystem administration and application save behavior remain with the appointed software and storage teams. This educational example does not define a Leviathan storage-administration or managed-cloud service.

References: [L1]