The mkdirs() in PathData.java file: I understand that it was added to help move FsShell to FileContext in an easier way. Since it looks like it might be out of place being in PathData.java, would it make sense to instead move it to Mkdirs.java. I understand that "fs" was moved to PathData to avoid the callers from having to deal/know about the "fs", but to me it looks better than having to call mkdirs() from PathData.java.
Yes, one of my end goals is greatly simplifying the switch to FileContext. I'm trying to make the FileSystem, FileContext, and/or anything else, opaque to the user of a path. This will afford us the ability to transparently use whatever is needed w/o modifying the callers when something changes.
If it was moved to a Mkdirs.java, that would set the precedent for every fs operation being a separate class which I don't think is very desirable. Having a mkdirs(PathData) would require that method to reach into the guts to get the fs or context which defeats the purpose of "hiding" it.
Regarding that horrible chunk of code that processes paths w/o an authority... The comment before it starts with "this is very nasty". It's entirely for backwards compatibility. If I were to do it for all paths, then other tests break. I want the initial redesign to be fully backwards compatible, then we can work on eliminating the gross inconsistencies in the code.
Sure, I'll make the references to path/string more consistent.
Thanks for the comments!