composefs / composefs/composefs
odd handling of `image_mountdir`
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 689
- Forks
- 56
- PR merge metrics
- No merged PRs in 30d
Description
I've been spending a lot of time in lcfs_mount lately and there are a few weird issues around options->image_mountdir.
-
this is specified by the user as a
const char *but we internally cast it tochar *so that we can pass it to some functions which require it to bechar *. But those functions don't modify it and can be changed to consumeconst char *without issue. -
in the normal exit path (error or not error) we check that we were the ones that created the temporary directory before we remove it:
if (created_tmpdir) {
rmdir(imagemount);
}
- but we have an early exit path which removes it unconditionally (if we failed to mount the erofs)
if (err < 0) {
rmdir(imagemount);
return err;
}
-
but maybe we just want to eliminate this feature entirely. It's used by nothing else inside of composefs itself. ostree uses it, though, so maybe we decide to keep it....
-
but in that case, we should definitely improve the const-correctness issues and also fix the bug where we rmdir() the user's directory in some error cases but not others
-
all of this goes a little bit towards how complicated the error handling in C in libcomposefs has become....
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in lcfs_mount and trace every use of options->image_mountdir, including the early EROFS mount-failure path and the normal cleanup path. Check the ostree usage before deciding whether to retain the option; done means the chosen behavior is consistent, user-owned directories are not removed, and the const-correctness issues are addressed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100