@nicholasbishop @GabrielMajeri I finally had time working on this. It is still not ready to merge but much closer now. I add it as a new workspace member uefi-fs. Let me know what you think.

API examples from the new integration test:

 let mut fs = FileSystem::new(sfs);
 fs.create_dir("test_file_system_abs").unwrap();
 // slash is transparently transformed to backslash
 fs.write("test_file_system_abs/foo", "hello").unwrap();
 // absolute or relative paths are supported; ./ is ignored
 fs.copy("\\test_file_system_abs/foo", "\\test_file_system_abs/./bar").unwrap();
 let read = fs.read("\\test_file_system_abs\\bar").unwrap();
 let read = String::from_utf8(read).unwrap();
 fs.rename("test_file_system_abs\\bar", "test_file_system_abs\\barfoo").unwrap();
 let entries = fs.read_dir("test_file_system_abs").unwrap()
 .map(|e| e.unwrap().file_name().to_string())
 .collect::<Vec<_>>();
 assert_eq!(&[".", "..", "foo", "barfoo"], entries.as_slice());

Looks nice!

A few thoughts and questions:

• Will a PathBuf API be provided as well? Wouldn't necessarily need to be in the initial PR.
• I think maybe instead of a new crate, we could put this as a module in the main uefi crate, e.g. uefi::fs. My reasoning is basically that unless the new code runs against one of a few specific cases I'll list below, it's easier on the end user to keep it in the main crate. This is relevant to those other tickets about features vs crates as well, and I intend to write up some more thoughts eventually. But briefly, the reasons I can think of to put it in a separate crate are:
  • If the new code increases the compile-time of the crate significantly then putting it in a separate crate makes sense. I don't think that's an issue here; compilation-time increases are often related to pulling in more dependencies, but the only new dep here is derive_more, which pulls in quote/syn/proc_macro2, all of which we already depend on because of uefi-macros. And the new code is not so large that it should meaningfully affect compilation times.
  • If the new code needs to be separated by a feature flag. Putting it in a separate crate can be a reasonable alternative to crate features, but in this case I think we can either gate the whole thing behind alloc, or maybe do it more fine-grained and just gate particular functions and types behind alloc. But it's not like, depending on new unstable features or anything.
  • If the new code would negatively affect the API of the uefi crate. I don't think there's any issue with that here, it could all be neatly contained in uefi::fs.
• Just a suggestion for examples and tests with paths containing backslashes, you can use r"a\b\c" as a slightly cleaner alternative to "a\\b\\c".

• Will a PathBuf API be provided as well? Wouldn't necessarily need to be in the initial PR.

So far, the API a user sees is just a &str. Internally, it is transformed to a normalized CString16. I do not have a Path/PathBuf implementation yet (that is meant to be public). I think in the long term, each method should consume fn foo<P: Into<&cstr16>(&self, path: P) or so, but I'm not sure about the interface. I think, it is most important that &str is accepted as path.

Internally, the separator is \\. However, users can just use a regular slash. The slash is transparently replaced by the internal path normalization process.

• I think maybe instead of a new crate, we could put this as a module in the main uefi crate, e.g. uefi::fs. My reasoning is basically that unless the new code runs against one of a few specific cases I'll list below, it's easier on the end user to keep it in the main crate. This is relevant to those other tickets about features vs crates as well, and I intend to write up some more thoughts eventually. But briefly, the reasons I can think of to put it in a separate crate are:

  • If the new code increases the compile-time of the crate significantly then putting it in a separate crate makes sense. I don't think that's an issue here; compilation-time increases are often related to pulling in more dependencies, but the only new dep here is derive_more, which pulls in quote/syn/proc_macro2, all of which we already depend on because of uefi-macros. And the new code is not so large that it should meaningfully affect compilation times.
  • If the new code needs to be separated by a feature flag. Putting it in a separate crate can be a reasonable alternative to crate features, but in this case I think we can either gate the whole thing behind alloc, or maybe do it more fine-grained and just gate particular functions and types behind alloc. But it's not like, depending on new unstable features or anything.
  • If the new code would negatively affect the API of the uefi crate. I don't think there's any issue with that here, it could all be neatly contained in uefi::fs.

I thought about it, and it doesn't massively increase compilation times nor requires it a feature flag. It will be just part of the normal API.

• Just a suggestion for examples and tests with paths containing backslashes, you can use r"a\b\c" as a slightly cleaner alternative to "a\\b\\c".

Ah, I didn't know that, thanks.

PS: This feature heavily uses (small and medium) allocations. In the long term, we might get some feedback in case our allocator does something wrong or so.

Ping @nicholasbishop ? :)

@nicholasbishop I think this is ready for review and merging, when we keep the following things in mind:

• So far, the public API change and exports are very small and unlikely to ever change. I'd like to keep it that way.
• Users only use &str to pass in paths at the moment. This will eventually by replaced by something like Into<Path>, where Path is part of a public API of the fs module. This will be subject of (follow-up) discussions (of a follow-up PR hopefully)
• I'm very unhappy with my internal implementation of NormalizedPath and path handling in general. However, as this is a purely internal API, I think I can fix this in a follow-up MR and finally merge this feature.
• I'm very happy with the state of the (public) documentation right now and how this simplifies things

Open Questions/Blockers:

• In my NormalizedPath abstraction I kept the way open for merging a path with a present working directory. The idea is that users specify FileSystem::set_pwd("/foo/kernel"). But I think, this is over-engineered and too feature-creep, aye?
• I need do double check that the integration test is sufficient.

I'm in favor of merging this once the tests are passing and the one todo!() is fixed. We can handle cleanups/additional tests in follow up PRs.