[discussion] ErrorKind::InvalidFilename from io_error_more

[GrigorenkoPV]

@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.

• FilesystemLoop: [discussion] ErrorKind::FilesystemLoop from io_error_more #130188
• FilesystemQuotaExceeded: [discussion] ErrorKind::FilesystemQuotaExceeded from io_error_more #130190
• CrossesDevices: [discussion] ErrorKind::CrossesDevices from io_error_more #130191
• InvalidFilename: you are here

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)

[tsuyoshi2]

"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...".

[joshtriplett]

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

[joshtriplett]

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]

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

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]

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

[rfcbot]

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.