Forbid reserved file names on Windows

[sanmai-NL]

Such as COM8.

See https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#naming_conventions

[udoprog]

This is probably out of scope for this library. But I'll change this one into a question in case anyone disagrees.

[ghost]

I don't think this is entirely out-of-scope if our end-goal is portability.

That said, this is a huge undertaking and will change the current semantics by quite a bit. To do this properly will require us to target "least common denominator" rather than just for Windows. We'll lose the ease of our paths being backed by str. Our paths have to be able to convert to any OsStr losslessly (if we were to maintain our vision).

It does make the entire crate more robust and much more appealing.

If anybody wants to push this through (major 2.0 version of this crate), I'm happy to participate in design discussions.

[udoprog]

I appreciate the input!

The biggest issue for me is that there's a lot and divergent filesystem rules for what constitutes a file that can be opened or created. All from the more obvious (reserved names) to the less so (permissions) to the even less so. Like non-typical filesystems could add other arbitrary restrictions in naming with the /proc filesystem on Linux being one such example. The only surefire way to really tell is to issue a system call and have the OS tell you.

That being said, maybe it's possible to add some checks which are valuable. If so, I'd be curious to hear what people have in mind and how to design APIs around them.

Just speculating, but maybe a custom but separate deserializer method could be useful, like:

struct Config {
    #[serde(deserialize_with = "relative_path::de::without_reserved_names")]
    path: RelativePathBuf,
}

[ghost]

I think it might be good to formulate what our target use-case is and discuss/optimize around that. The total set of external rules possible, when combined, might mean that there can never be portable file names ever. We'll have to list some assumptions.

My assumed scenario is that:

1. there is a set of files packaged together with an application meant to be deployed across different platforms,
2. the set of files will have their organization unchanged from a base path no matter the platform,
3. any config/manifest files will point towards an existing file that comes packaged with the application,
4. the author has full control over these file names.

(feel free to add/modify these assumptions)

Given these, relative_path should create its own (reasonable) standard about how files should be named and require users to play by them. We want portability hazards to fail as early as possible, preferably when the author test it in their own development environment.

Currently, if you test your apps in a unix environment and have given relative paths like "foo/C:/bar", the crate doesn't really help since the failure will only manifest when tested on a Windows machine. One could equally well have just stored it as a String, especially since RelativePath doesn't even check for backslashes as part of the requirements to create it. The path types exposed by this crate should ideally hold stronger invariants than its underlying String.

I think starting with rejecting backslashes and reserved names across common platforms could be good. We could also enforce no using of silly path constructions like empty components (as in "foo//bar") etc. etc. while we're at it.

What are your thoughts?

[sanmai-NL]

My proposal isn't on permissions. There is logic around that. Using errors programmers handle that in specific ways. /proc isn't an invalid path by definition, but another case of permissions/application logic. I want to filter out names that are invalid or unportable by definition.