Add single file mount support via hardlink-based isolation for single file mounts

[Sunsvea]

Summary

Fixes #79 by adding single file mount support, and mount consolidation for multiple single file mounts targeting the same parent directory.

Changes

• Mount consolidation: Groups multiple single file mounts by parent directory into a single VirtioFS share
• Caching mechanism: Added consolidatedMountsCache so both toVZ() and mountAttachments() use the same consolidated instances for hash consistency
• Hardlink isolation: Files are isolated using hardlinks in temporary directories, then the entire directory is mounted to the parent path

Example:

• Single file: /host/config.txt → /app/config.txt (creates isolated hardlink share)
• Multiple files to same parent:
  • Both /host/config.txt → /app/config.txt and /host/secret.txt → /app/secret.txt get consolidated into a single VirtioFS share mounted at /app/ containing both files as hardlinks

This enables container configurations like:
config.mounts.append(.share(source: "/host/config.txt", destination: "/app/config.txt"))
config.mounts.append(.share(source: "/host/secret.txt", destination: "/app/secret.txt"))

Testing

Unit tests (MountTests.swift):

• fileDetection - verifies file mount detection and properties
• attachedFilesystemBindFlag - tests AttachedFilesystem configuration for files
• hardlinkIsolation - validates hardlink creation and deterministic directories
• fileMountDestinationAdjustment - checks destination path adjustment for file mounts

Integration tests (VMTests.swift):

• testSingleFileMount - single file mount functionality
• testMultipleSingleFileMounts - multiple files to same parent directory

[Sunsvea]

Tonight I'll add integration tests and some extra coverage for error conditions (file doesn't exist, permission denied), symlinks, malicious paths, etc.

Just wanted to get the PR up to elicit early feedback.

[dcantah]

Will look after the integration test(s) are added. Can you make fmt tonight as well to make CI nice and happy? Thanks for workin on this!

[dcantah]

Couple quick thoughts

[Sunsvea]

Integration tests added for:

• testSingleFileMount
• testMultipleSingleFileMounts

Unit tests added:

• emptyFileMount
• specialCharactersInFilename
• hiddenFileMount
• readOnlyFileMount

[Sunsvea]

Let me know if you have any more thoughts, thanks @dcantah.

I'm off for the night and can address any further feedback in the morning. 👍🏼

Just saw your comment here too. Will reply once I can revisit this in the morning, as I have some thoughts here. Appreciate the depth!

[Sunsvea]

Pushed some changes... Shifting the approach from sharing parent dirs to using hardlink-based file isolation as suggested by @dcantah here

[dcantah]

@Sunsvea Can you take a look at the test failures?

[Sunsvea]

Thanks @dcantah

Looks like there was an issue when mounting multiple single files to the same parent directory. The mount consolidation logic was running twice - once during VM configuration and once during container processing - creating different consolidated mount instances with different hashes.

To fix this I added a caching mechanism (consolidatedMountsCache) so both toVZ() and mountAttachments() use the same consolidated mount instances for hash consistency.

The consolidation logic itself works as intended: groups multiple single file mounts targeting the same parent directory into a single VirtioFS share, with files isolated using hardlinks in a temporary directory.

Any thoughts on this approach?

[Sunsvea]

Pushing some more changes shortly to cover a few extra scenarios:

• Atomic directory creation (prevent TOCTOU race conditions)
• File input validation (reject symlinks / is readable file)
• Temp dir cleanup

[Sunsvea]

Converted to Draft PR while I investigate the failures when tests are run in parallel.

[Sunsvea]

The naming/mounting conflicts for the tests should be resolved now.... Tried replicating the CI conditions the best I could locally.

[Sunsvea]

@dcantah Any thoughts on this one?

[dcantah]

Trying to find time to review, sorry for the delay

[ezintz]

we would like to use apple container, would be great to have this merged and released if there are no concerns?

[Sunsvea]

we would like to use apple container, would be great to have this merged and released if there are no concerns?

I can continue supporting this PR if it moves forward, but I should be transparent with @dcantah that I recently joined Apple and so there may (?) be a conflict of interest. I’m happy to move forward if he decides it is the best direction to take.