Skip to content

Directory write check logic sits better in shim - #1386

Open
Jay Bosamiya (Microsoft) (jaybosamiya-ms) wants to merge 2 commits into
mainfrom
jayb/directory-write-check-shim
Open

Jay Bosamiya (Microsoft) (jaybosamiya-ms) wants to merge 2 commits into
mainfrom
jayb/directory-write-check-shim

Conversation

@jaybosamiya-ms

@jaybosamiya-ms Jay Bosamiya (Microsoft) (jaybosamiya-ms) commented Sep 16, 2026

Copy link
Copy Markdown
Member

This PR decides to explicitly diverge the LiteBox core file system semantics from POSIX. It is part of the longer-term plan to move away from the OFlags and use a more broader-applicable abstraction there anyways. Roughly, POSIX requires that open of O_WRONLY or such on a directory should return an EISDIR. However, this is a shim-level concern, and the core should not be concerned with this sort of semantics. Thus, I've moved this decision into the shim.

Comment on lines -368 to +384
files
let file = files
.fs
.open(&context, path, flags - OFlags::CLOEXEC, mode)
.map_err(Errno::from)
.map_err(Errno::from)?;
if flags.intersects(OFlags::WRONLY | OFlags::RDWR)
&& !flags.contains(OFlags::PATH)
&& files
.fs
.fd_file_status(&file)
.map_err(Errno::from)?
.file_type
== litebox::fs::FileType::Directory
{
files.fs.close(&file).unwrap();
return Err(Errno::EISDIR);
}
Ok(file)

@jaybosamiya-ms Jay Bosamiya (Microsoft) (jaybosamiya-ms) Sep 16, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yes, this does mean that any writable open of a file suffers an additional status check, but I think the simplification of the semantics and the unblocking of the Windows side (on ulitebox) is worth this tiny and rare inefficiency. Most programs are not constantly opening+closing writable files: usually the write itself is the bottleneck, so I think this is a reasonable tradeoff to make.

@jaybosamiya-ms

Copy link
Copy Markdown
Member Author

Related: #1255 (specifically, see a871fb5) and #894 (afe6cdd)

@github-actions

Copy link
Copy Markdown

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.

@wdcui Weidong Cui (wdcui) left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

LGTM. Thanks.

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.

2 participants