Honor the requested mode in the Windows access provider
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 75/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- rust
- Domain
- cli, operating-systems
Research direction
The issue is in the file std/sys/windows/fs.wave. Start by reading the access function in that file to see how it currently ignores the mode parameter. Compare with other platform implementations to understand the expected behavior. Implement the mode checks using Windows API calls (like GetFileAttributes for existence, and perhaps CreateFile with desired access to test readability/writability). Write tests in the same file or a corresponding test module to verify existence (FS_F_OK), readable (FS_R_OK), and non-writable (FS_W_OK on a read-only file) cases. Ensure failures return the correct portable error codes.
Written by the indexing model from the issue text.
Description
Problem
std/sys/windows/fs.wave exposes FS_F_OK, FS_X_OK, FS_W_OK, and FS_R_OK, but access(path, mode) never reads mode. Any existing path therefore succeeds regardless of the requested access check, so a write check currently behaves the same as an existence check.
Other filesystem providers pass the requested mode through to their native access primitive, so the Windows provider does not preserve the portable contract.
Completion criteria
- Keep
FS_F_OKas an existence check. - Make nonzero access modes affect the Windows result instead of being ignored.
- Ensure a read-only file does not report writable for
FS_W_OK. - Define and test the Windows behavior for the exported
FS_R_OKandFS_X_OKmodes. - Return the existing portable negative error codes on failure.
- Add focused Windows regression coverage for existence, readable, and non-writable cases.
Difficulty: easy.
- Dominant language
- Rust
- Stars
- 53
- Forks
- 16
- Avg merge
- 3h 38m
- Merged PRs (30d)
- 48
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.
More from wavefnd/Wave
-
enhancement good first issue needs testing
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
enhancement good first issue needs testing
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
bug ci good first issue needs testing
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
bug ci good first issue needs testing
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
bug good first issue needs testing
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Similar issues
-
bug github_actions
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
registrystack/registry-stack#1393 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
longbridge/gpui-kit#3223 ·
-
bug engine
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
rocky-data/rocky#2181 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
oasisprotocol/oasis-sdk#2523 ·
-
[indexer] [QA] Add a focused test for the new NonRetryableError / assertSocketAlive() behavior. Openbot:ai-assisted component:indexer QA-roadmap status:untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
midnightntwrk/midnight-indexer#1557 ·