Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[discussion] ErrorKind::InvalidFilename from io_error_more #130192

Open
GrigorenkoPV opened this issue Sep 10, 2024 · 6 comments
Open

[discussion] ErrorKind::InvalidFilename from io_error_more #130192

GrigorenkoPV opened this issue Sep 10, 2024 · 6 comments
Labels
C-discussion Category: Discussion or questions that doesn't represent real issues. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. to-announce Announce this issue on triage meeting

Comments

@GrigorenkoPV
Copy link
Contributor

@rustbot label C-discussion

Main tracking issue: #86442

Background

The io_error_more feature introduced 21 new variants into ErrorKind. They were FCP'd back in December 2022, but there appeared to be quite a lot of disagreement about 4 of the added variants, so the stabilization (#106375) got stalled for over twenty months. Thankfully, the 17 uncontroversial variants got stabilized in #128316, so now we just need to iron out a satisfactory design for the remaining 4 variants, and then they can be stabilized too.

In order to not block any of the remaining variants on each other and to not intertwine the discussions, I've created 4 separate issues, which summarize the concerns & suggestions voiced up until this point and can serve as a place for further discussion.

InvalidFilename

Currently corresponds to ENAMETOOLONG on Unix, ERROR_FILENAME_EXCED_RANGE & ERROR_INVALID_NAME on Windows. (#86442 (comment))

Current docs description:

A filename was invalid.

This error can also cause if it exceeded the filename length limit.

Docs

I'm not sure "This error can also cause if it exceeded the filename length limit." is well-formed coherent English, but I'm not a native speaker.

Name capitalization

std uses file_name in functions, rather than filename. It'd be odd to break correspondence between snake_case and CamelCase, so I think this should be FileNameTooLong to match. Same goes for InvalidFileName.

Originally posted by Kornel in #79965 (comment)

Separate "the name is too long" case

I might be a little too late, but I'm not sure combining ERROR_FILENAME_EXCED_RANGE and ERROR_INVALID_NAME into InvalidFilename is a good idea. What was the reason behind this decision?

For example if one is writing an unarchiver to extract files, if a filename is too long one could simply truncate the filename and tell the user this. But if the filename is invalid/reserved (eg. COM) then the name would have to be completely different.

An app could guess which of the two it is, but it would be more straightforward if the two are distinguished from the start.

Originally posted by cktkw in #86442 (comment)

There is a long reply from Aritz Beobide-Cardinal in #106375 (comment) arguing against the separation.

Map more raw os errors to this ErrorKind

I was speculating there might be an OS that returns "Invalid Filename" when the filename is too long.
In which case, this decision will make sense.
But otherwise, "Filename Too Long" is one of the few errors that seem to be consistent among platforms.

With current PR, Unix doesn't have InvalidFilename mapped to anything else (at least from my quick skim through sys/unix/mod.rs).
However, UNIX-like OS fails with varying error when invalid UTF-8 filename is used to open() in C.
Mac APFS fails with EILSEQ (Illegal byte sequence).
Linux EXT4 (formatted with strict case-insensitive option -O casefold -E encoding_flags=strict, because otherwise any byte sequence is allowed) fails with EINVAL(invalid argument).

In theory, I think these should be mapped to InvalidFilename in the context of File::open(), File::create(), etc. But I understand that that would need major rewrite.
I don't know enough to say what would be the best way, but current use of InvalidFilename doesn't feel optimal.

Originally posted by cktkw in #86442 (comment)
@rustbot rustbot added needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. C-discussion Category: Discussion or questions that doesn't represent real issues. labels Sep 10, 2024
@tsuyoshi2
Copy link

"This error can also cause if..." is, indeed, improper English. "Cause" is a transitive verb. It can be rephrased in the passive voice as "This error can be caused if...".

@dtolnay dtolnay added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Sep 10, 2024
This was referenced Sep 10, 2024
Open
Closed
@rulu158 rulu158 mentioned this issue Sep 27, 2024
Open
@GrigorenkoPV GrigorenkoPV mentioned this issue Oct 10, 2024
Closed
@jieyouxu jieyouxu removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Oct 10, 2024
@joshtriplett
Copy link
Member

Alternative rephrasing: "This error can also occur if ..."

@joshtriplett
Copy link
Member

I'm going to propose that we stabilize this as InvalidFilename. (We don't need to block this FCP on wordsmithing the documentation.)

@rfcbot merge

@rfcbot
Copy link

rfcbot commented Nov 8, 2024 •
edited by Amanieu
Loading

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Nov 8, 2024
@GrigorenkoPV GrigorenkoPV mentioned this issue Dec 9, 2024
Merged
@GrigorenkoPV GrigorenkoPV mentioned this issue Dec 22, 2024
Merged
@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Feb 11, 2025
@rfcbot
Copy link

rfcbot commented Feb 11, 2025

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. to-announce Announce this issue on triage meeting and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Feb 21, 2025
@rfcbot
Copy link

rfcbot commented Feb 21, 2025

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

@rustbot rustbot mentioned this issue Feb 21, 2025
Open
3 tasks
jieyouxu added a commit to jieyouxu/rust that referenced this issue Mar 12, 2025
@jieyouxu
Rollup merge of rust-lang#134076 - GrigorenkoPV:InvalidFilename, r=jo…
fa678e4 
…boet

Stabilize `std::io::ErrorKind::InvalidFilename`

FCP complete: rust-lang#130192 (comment)

Tracking issues: rust-lang#86442 & rust-lang#130192

This PR:
- Stabilizes `InvalidFilename` without changing its name to `InvalidFileName`.
- Fixes the doc comment (rust-lang#130192 (comment))
- Does not separate "the name is too long" case into a separate `ErrorKind`. That case is currently documented to be covered by `InvalidFilename` in the doc. I'm not sure if it would be possible to change this later or if that would be an unacceptable breaking change.
- Does not map more raw OS errors to this `ErrorKind` (as suggested in rust-lang#86442 (comment)). This can presumably be addressed later.
jieyouxu added a commit to jieyouxu/rust that referenced this issue Mar 12, 2025
@jieyouxu
Rollup merge of rust-lang#134076 - GrigorenkoPV:InvalidFilename, r=jo…
fc97d9c 
…boet

Stabilize `std::io::ErrorKind::InvalidFilename`

FCP complete: rust-lang#130192 (comment)

Tracking issues: rust-lang#86442 & rust-lang#130192

This PR:
- Stabilizes `InvalidFilename` without changing its name to `InvalidFileName`.
- Fixes the doc comment (rust-lang#130192 (comment))
- Does not separate "the name is too long" case into a separate `ErrorKind`. That case is currently documented to be covered by `InvalidFilename` in the doc. I'm not sure if it would be possible to change this later or if that would be an unacceptable breaking change.
- Does not map more raw OS errors to this `ErrorKind` (as suggested in rust-lang#86442 (comment)). This can presumably be addressed later.
Manishearth added a commit to Manishearth/rust that referenced this issue Mar 12, 2025
@Manishearth
Rollup merge of rust-lang#134076 - GrigorenkoPV:InvalidFilename, r=jo…
185dd2d 
…boet

Stabilize `std::io::ErrorKind::InvalidFilename`

FCP complete: rust-lang#130192 (comment)

Tracking issues: rust-lang#86442 & rust-lang#130192

This PR:
- Stabilizes `InvalidFilename` without changing its name to `InvalidFileName`.
- Fixes the doc comment (rust-lang#130192 (comment))
- Does not separate "the name is too long" case into a separate `ErrorKind`. That case is currently documented to be covered by `InvalidFilename` in the doc. I'm not sure if it would be possible to change this later or if that would be an unacceptable breaking change.
- Does not map more raw OS errors to this `ErrorKind` (as suggested in rust-lang#86442 (comment)). This can presumably be addressed later.
jieyouxu pushed a commit to jieyouxu/rustc-dev-guide that referenced this issue Mar 13, 2025
@Manishearth
Rollup merge of #134076 - GrigorenkoPV:InvalidFilename, r=joboet
a879001 
Stabilize `std::io::ErrorKind::InvalidFilename`

FCP complete: rust-lang/rust#130192 (comment)

Tracking issues: #86442 & #130192

This PR:
- Stabilizes `InvalidFilename` without changing its name to `InvalidFileName`.
- Fixes the doc comment (rust-lang/rust#130192 (comment))
- Does not separate "the name is too long" case into a separate `ErrorKind`. That case is currently documented to be covered by `InvalidFilename` in the doc. I'm not sure if it would be possible to change this later or if that would be an unacceptable breaking change.
- Does not map more raw OS errors to this `ErrorKind` (as suggested in rust-lang/rust#86442 (comment)). This can presumably be addressed later.
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Mar 14, 2025
@Manishearth
Rollup merge of #134076 - GrigorenkoPV:InvalidFilename, r=joboet
2f7efab 
Stabilize `std::io::ErrorKind::InvalidFilename`

FCP complete: rust-lang/rust#130192 (comment)

Tracking issues: #86442 & #130192

This PR:
- Stabilizes `InvalidFilename` without changing its name to `InvalidFileName`.
- Fixes the doc comment (rust-lang/rust#130192 (comment))
- Does not separate "the name is too long" case into a separate `ErrorKind`. That case is currently documented to be covered by `InvalidFilename` in the doc. I'm not sure if it would be possible to change this later or if that would be an unacceptable breaking change.
- Does not map more raw OS errors to this `ErrorKind` (as suggested in rust-lang/rust#86442 (comment)). This can presumably be addressed later.
github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this issue Mar 14, 2025
@Manishearth
Rollup merge of rust-lang#134076 - GrigorenkoPV:InvalidFilename, r=jo…
68f6d81 
…boet

Stabilize `std::io::ErrorKind::InvalidFilename`

FCP complete: rust-lang#130192 (comment)

Tracking issues: rust-lang#86442 & rust-lang#130192

This PR:
- Stabilizes `InvalidFilename` without changing its name to `InvalidFileName`.
- Fixes the doc comment (rust-lang#130192 (comment))
- Does not separate "the name is too long" case into a separate `ErrorKind`. That case is currently documented to be covered by `InvalidFilename` in the doc. I'm not sure if it would be possible to change this later or if that would be an unacceptable breaking change.
- Does not map more raw OS errors to this `ErrorKind` (as suggested in rust-lang#86442 (comment)). This can presumably be addressed later.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-discussion Category: Discussion or questions that doesn't represent real issues. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this PR / Issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. to-announce Announce this issue on triage meeting
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@joshtriplett @tsuyoshi2 @dtolnay @rfcbot @jieyouxu @rustbot @GrigorenkoPV