Skip to content

Conversation

Johan-Liebert1
Copy link
Collaborator

Read inline inode entries if not empty

Read inline inode entries if not empty

Signed-off-by: Pragyan Poudyal <[email protected]>
}

if inode.mode().is_dir() {
if !inode.inline().is_empty() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you have a reason to change the traversal ordering too so the tail block is traversed first?

this.visit_nid(&img, nid)?;
}
Ok(this.objects)
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FTR I think it'd be relatively straightforward to generate unit tests for all of this code.

Copy link
Collaborator

@allisonkarlitskaya allisonkarlitskaya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on wondering why the order had to change... it seems a bit odd.

The commit message could be a bit better. Why did you hit this? Is there some error elsewhere with handling empty blocks? Or is it a general cleanup kind of thing?

Thanks!

cgwalters added a commit to cgwalters/composefs-rs that referenced this pull request Oct 15, 2025
…ry bug

Add a comprehensive regression test that reproduces the bug fixed in PR
inline directory sections as DirectoryBlock, causing a panic.

The test generates an erofs image on-the-fly using C mkcomposefs, which
(unlike the Rust implementation) creates directories with empty inline
sections. This reveals a key difference: the C implementation stores only
the parent reference without . and .. entries when a directory is empty,
while the Rust implementation always includes those entries.

The test demonstrates both:
1. A synthetic case showing DirectoryBlock::n_entries() panics on empty
   inline data
2. The actual bug triggered by collect_objects() on the C-generated image

The test is marked #[ignore] so it doesn't break CI until PR containers#188's fix
is applied. When run with --ignored, it passes by catching the expected
panics.

Asissted-by: Claude Code
Signed-off-by: Colin Walters <[email protected]>
@cgwalters
Copy link
Collaborator

Can we land #189 and then this can be rebased on top ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants