Draft: Switch fs2 to fs4 as it is now unmaintained and does not support illumos

[Toasterson]

Cargo test passes tests and API is compatible.

[fulmicoton]

@Toasterson Is it something you need? fs4 does not seem to be well adopted yet.

[Toasterson]

Yes something where danburkert/fs2-rs#32 has a chance to be merged and not get stuck for 3 years.

[fulmicoton]

@Toasterson You do use illumos and want to use tantivy on it?

[fulmicoton]

@Toasterson Let me explain why am I asking. fs4 does not seem very popular. Switching from one crate to another like imply a security risk. How do we know that this is not a fork containing malicious code without auditing the code?

[Toasterson]

Yes I run illumos and want to run Plume Blog on it which uses tantivy. I am a Maintainer of the OpenIndiana distribution. I don't know what your policies for audits are but fs4 is not big enough to introduce a large audit and rustix is from the bytecode alliance which is a trustworthy entity in terms of malicous code. Although I still need to fix some of rustix's cfg macros which for some reason exclude all solarish operating systems even though they don't need to.

[Toasterson]

I may also look for an alternative. rustix is a curious maze of exports and all of them block illumos. But there would need to be another maintainer for fs2 so we can merge the PR's. Or I'll be keeping a private fork with a custom fs2 repo.

[Toasterson]

One of our community people at Oxidecomputer has made a fork with some patches if that is more to your liking https://github.com/oxidecomputer/fs3-rs

[fulmicoton]

@Toasterson thank you I'll try and find a solution on Monday

[fulmicoton]

@Toasterson thank you for your patience.

[ryanavella]

I saw this linked in the fs2 issue tracker so thought I'd chime in here for posterity, as someone who has looked into fs2 alternatives and attempted to audit some of fs4 myself.

fs4 does not seem very popular. Switching from one crate to another like imply a security risk. How do we know that this is not a fork containing malicious code without auditing the code?

This is a good point, and not something I'm particularly thrilled about. But as matters stand now, fs2 contains logic bugs that make it somewhat buggy on Linux, and borderline unusable on other OS's. I can't necessarily vouch for fs4 security-wise, but assuming we could audit it in full, I think it is the most promising of the fs2 forks. (more on that below)

One of our community people at Oxidecomputer has made a fork with some patches if that is more to your liking https://github.com/oxidecomputer/fs3-rs

I initially thought the same thing, but unfortunately fs3 is archived as read-only despite it sharing a number of logic bugs with fs2. For example, the posix_fallocate issues on Linux and FreeBSD+ZFS are still there, last I checked.

From a maintainability perspective, I think fs4 or a lower-level alternative (libc/nix/rustix) is better than fs3 in this regard.

[Toasterson]

fs4 yes but rustix needs a lot of adaptations and bugs not present in nix/libc are now present in rustix. Mainly we now have to selectively enable each feature which is hidden somewhere behind 5 re-exports. It's a weird crate. Anyway, I am apparently committed to fixing rustix anyway let's see when I start understand that mess.