The whole handling of fsreadfd and fswritefd makes me itch. They are opened and closed at random places, and some places test for them being < 0, but they are not statically initialized to -1 nor set to -1 when closed. I would honestly not be surprised if there were some weird combination of options that caused data blocks to be written to stdin rather than the disk.

Not to mention that fsreadfd can be opened as many as three times, with the descriptor leaked twice; this is pretty harmless, but it shows to what extent the code is a mess.

In D30880#694777, @andrew_tao173.riddles.org.uk wrote:

Not to mention that fsreadfd can be opened as many as three times, with the descriptor leaked twice;

I count four, leaked once - where's the second one?
open(fsreadfd) called @ Line 276, 296, 343 (sbin/fsck_ffs/main.c) and Line 130 (sbin/fsck_ffs/setup.c).
@line 276, is a block of code that opens fsreadfd, closes it, and exits.
@line 296, these ones could be leaked here, I'll update the revision to address that.
@line 343, opens fsreadfd and either exits or closes fsreadfd and continues on.

@line 130 (sbin/fsck_ffs/setup.c): fsreadfd is opened by setup() until program exit.

I count two times where fswritefd is opened;
Line 298 (sbin/fsck_ffs/main.c): fswritefd could be leaked here, I'll update the revision.
Line 175 (sbin/fsck_ffs/setup.c): fswritefd is opened by setup() and used till program exit

Maybe it'd be nice if the read/write fd's were handled by libufs, but then again maybe not - I couldn't say without studying the code a bit more.

Maybe it'd be nice if the read/write fd's were handled by libufs, but then again maybe not - I couldn't say without studying the code a bit more.

There was an earlier attempt to use libufs in fsck, but fsck needs more capabilities than libufs supports, sofsck now just handles all the I/O itself.