composefs / composefs/composefs

odd handling of `image_mountdir`

Open
#359 1 comment 0 reactions 0 assignees View on GitHub

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 to char * so that we can pass it to some functions which require it to be char *. But those functions don't modify it and can be changed to consume const 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.