Skip to content

Improve OpenOptions append+truncate error message - #160719

Open
BartSimpson001 wants to merge 1 commit into
rust-lang:mainfrom
BartSimpson001:fix-160716
Open

Improve OpenOptions append+truncate error message#160719
BartSimpson001 wants to merge 1 commit into
rust-lang:mainfrom
BartSimpson001:fix-160716

Conversation

@BartSimpson001

@BartSimpson001 BartSimpson001 commented Aug 7, 2026

Copy link
Copy Markdown
  • I did not use an LLM to create a change in this PR.
  • I used an LLM to create a change in this PR, and I have explained below how it was used.

An LLM (ChatGPT) was used to understand the codebase, locate the relevant platform-specific implementations and test files (unix.rs, windows.rs, and tests.rs), review the existing implementation, and assist in updating the test assertions to match the new error message. The final implementation, tests, and PR contents were manually reviewed and verified before submission.

Fixes #160716.

When OpenOptions is configured with both append(true) and truncate(true), the previous InvalidInput error message was:

creating or truncating a file requires write or append access

This message is misleading because append(true) already provides append access. This change replaces it with a more descriptive error message indicating that append and truncate cannot both be enabled at the same time.

The corresponding platform-specific tests have been updated to verify the new error message and ensure consistent behavior across the relevant implementations.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 7, 2026
@rustbot

rustbot commented Aug 7, 2026

Copy link
Copy Markdown
Collaborator

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @JohnTitor (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue
Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: @ChrisDenton, libs
  • @ChrisDenton, libs expanded to 13 candidates
  • Random selection from JohnTitor, Mark-Simulacrum, clarfonthey, nia-e

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

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

OpenOptions with append & truncate enabled: misleading error message

4 participants