The WAN Storage Dilemma
If your company has an office in New York and another in London, sharing large media files is an architectural nightmare. Historically, the industry has offered two deeply flawed solutions: Network Attached Storage (NAS) over a VPN, or automated file synchronization.
If you use an SMB or NFS share over a WAN, the latency kills you. Every time you open a folder, your computer sends hundreds of chatty metadata requests across the ocean just to draw the icons. If you use a sync tool like Dropbox, Google Drive, or Resilio, you solve the latency problem by downloading the files locally. But now, if New York ingests 20TB of 8K video, London's local server gets completely filled up downloading data they might never even open.
The Data Hoarder
To make the file appear in your local directory, the system must download the entire payload. You waste massive amounts of local disk space and internet bandwidth replicating data "just in case" someone needs it.
The Master Illusionist
The system downloads a 300-byte JSON instruction. It instantly draws a fake 50GB file in your local directory. The actual data stays remote, and is only streamed over the network when an application demands it.
We needed the instantaneous directory browsing of a local sync, without the catastrophic storage tax of actually copying the data. Enter the Ghost Stub.
Ftruncate: The Magic of Sparse Files
To understand how Husk pulls off this trick, you have to understand how operating systems think about file sizes. A file actually has two distinct size metrics: its Apparent Size (where the logical End-of-File marker is placed) and its Allocated Blocks (how many physical sectors on the hard drive it occupies).
Usually, these numbers match. But in Unix-like systems (Linux, macOS), there is a standard POSIX system call named ftruncate. It allows a programmer to push the End-of-File marker out to an arbitrary number—say, 50 Gigabytes—without actually writing any blocks to the disk. This creates a "sparse file."
Notice the 0 at the beginning of the second command? This 50GB video file is consuming exactly zero bytes of physical SSD space on this server. To the operating system, it looks like a massive file composed entirely of zeroes.
But we don't want zeroes. We want the real video data. To achieve this, Husk tags the sparse file with an Extended Attribute (xattr). We stamp trusted.husk.status = "stubbed" onto the file. This hidden metadata tag is the signal to the local Husk core that this file is an illusion.
Synchronizing the Illusion
How do these sparse files actually get created across the globe? It's powered by the Grid Mesh, a peer-to-peer TCP networking layer built into the Husk Enterprise Sidecar.
When an artist in New York drops a new 50GB file into their Husk-watched folder, the New York Sidecar intercepts the database update. It instantly broadcasts a tiny metadata payload to every other Husk Sidecar in the network.
{"mesh_action": "SYNC_DB_ROW", "file_path": "tokyo_shoot.mxf", "payload_size": 53687091200}