In rare situations, this might cause 2 times a root_hold_delay: if devices that need fsck appear later and other devices for mountcritlocal appear even later. I suppose it is not a major issue. Fixing it would probably require giving up the separation of fsck and mountcritlocal.

OK for the bin/sh/parser.c change.

This may lead to somewhat ugly messages like

-/bin/sh: Syntax error: ")" unexpected

for newgrp -l (where -sh: used to appear) but I think newgrp is not used often enough to warrant making this more complicated.

In D5977#129534, @kristof wrote:

In D5977#129496, @jilles wrote:

This is good because it looks like it will at least prevent the panic, but it may not make the files accessible since there need not be a short name. Adding a comment may be appropriate.

It's my understanding that there should always be a short filename (to keep the fs usable as a plain fat fs). I've deliberately chosen to use that one instead of truncating the name (as netbsd does) to avoid getting in the situation where two directory entries have the same (truncated) name.

This is good because it looks like it will at least prevent the panic, but it may not make the files accessible since there need not be a short name. Adding a comment may be appropriate.

I think the idea of sourcing the rc.d script is good but the implementation here has some issues.

Looks good to me (but probably avoid MFC).

Looks good to me.

This adds a requirement that the test be run as root and that securelevel be -1 or 0, which may not be desirable. To prevent compatibility problems, a line

TEST_METADATA.truncate_test+=  required_user="root"

should be added to usr.bin/truncate/tests/Makefile.

Looks good to me.

In D4412#98339, @ed wrote:

Done! I think that for now it makes sense to pick the following middle ground:

• Let the tests use nrand48().
• Initialize the random state with arc4random_buf().

This means that we still have the advantage of not fixing the test to a single sequence (which may not provide full coverage), but still allow for changing the test to use a fixed sequence in case we want to narrow down problems. Is this acceptable?

In D4412#97602, @ed wrote:

In D4412#97496, @jilles wrote:

A deterministic random number generator may be more useful for the test, so that runs can be reproduced.

Looks good to me otherwise.

Which random number generator do you suggest should be used in this case? Are *rand48() good for this purpose?

A deterministic random number generator may be more useful for the test, so that runs can be reproduced.

I noticed two unexpected return -1. They are not a memory leak but inconsistent.

I tried various locales and the output looks good to me. I found one minor nit in the code.