Closed cyphar closed 2 months ago
Or maybe you could make the API for try_clone
be the same as it currently is, but there is a way you can consume a Root
(or Handle
) and turn it into a builder?
let root = old_root.try_clone()?.rebuild().set_some_config().build()?; // maybe?
The other problem is what should Root::resolve
return? A builder? Does that really make too much sense? Handle
s don't really have a nice point where you can insert a constructor-like setup...
I ended up going with:
let root = Root::open(rootdir)?;
// Apply ResolverFlags::NO_SYMLINKS for a single operation.
root.as_ref()
.with_resolver_flags(ResolverFlags::NO_SYMLINKS)
.mkdir_all("foo/bar/baz", &perm)?;
// Create a temporary RootRef to do multiple operations.
let root2 = root
.as_ref()
.with_resolver_flags(ResolverFlags::NO_SYMLINKS);
root2.create("one", &InodeType::Directory(perm))?;
root2.remove_all("foo")?;
The current method of configuration is a really bad idea (exposing structure internals of
Root
is going to cause problems, I can feel it in my bones). So we should instead use a different design, but it's unclear to me what the best approach is:Just have methods to set (and possibly get) configuration of the object. It's not the nicest thing in the world, but it's fairly workable.
The most common approach is the "builder" method. The issue with it is whether there should be a way to modify the configuration after you've consumed the builder. If yes, then what is the point of the builder (you could just modify the configuration and not have a builder -- which is the alternative proposal). If no, and then how do we expose the builder method through the C API -- we'd need to have C builders which is just going to be absolutely awful.
Some follow-on questions (and my tentative answers):
Do people really care about modifying the configuration after the fact?
How do we deal with the
try_clone
case and modifying the configuration of the copy (ditto forfrom_file_unchecked
)?