Aleksa Sarai

For all of our other operations, it makes sense to reject dangling symlinks outright because they can just be treated as any other parent directory `ENOENT`, a regular `ENOENT`, or...

> I suspect that a far more preferable approach will be to relicense the core Rust code as MPL-2.0 (which is still copyleft, but friendly to Rust and other modern...

We can't delete the top-level directory but it would be nice to be able to delete everything inside a root this way.

We currently try to generate a report from test coverage files that were produced by binaries build with different feature flags. This is not really correct AFAICS -- the instruction...

This logic was added back when we were trying to defend against being tricked into walking into an attacker-controlled directory, but this was all ripped out in commit ce6226e473e5f72a95eb026293bbce278e55162f ("Root::mkdir_all:...

A classic issue you run into with unprivileged programs is that they cannot recursively remove `chmod 000` directories (even if they own them). The solution is fairly trivial (just chmod...

We can add a custom metadata field (i.e., `[metadata.com.cyphar.pathrs]` or something) to `Cargo.toml` and parse it from `build.rs` rather than just using the major part of the crate version --...

Root: should we have Root::open_subpath_follow?

1

At the moment the only API we have which controls follow-trailing-symlink behaviour with `O_NOFOLLOW` is `Root::open_subpath`. Maybe we should just have `Root::open_subpath_follow` and `Root::open_subpath`?

root: should Root::resolve_nofollow actually be flipped to Root::resolve_follow?

1

All of our internal APIs make the assumption that the more common case is that we do not want to follow trailing symlinks. This is true for how we've implemented...

We added a bunch of `@LIBPATHRS_0.1`symbols in #257 but we almost certainly had no C users before 0.2 (and likely won't have any until 0.3) so these symbols should probably...