Enhance init.d/bootmisc to skip wiping tmpfs-mounted dirs

[www.google.com/accounts/o8/id?id=aitoawkwxks0yu8ds1jw9yteckfs0bxwogv8lze]

Hi Roy,
I prepared a small patch to init.d/bootmisc, adding a few lines to check if a directory it’s considering for wiping is really on tmpfs; if so, no operation occurs.
This assumes safely enough that bootmisc is run upon boot, so any tmpfs filesystem will be empty, no need to hunt for files to delete, and no pointless “Wiping...” messages at the console.

[www.google.com/accounts/o8/id?id=aitoawkwxks0yu8ds1jw9yteckfs0bxwogv8lze]

By the way, I do have a name, that’s Raffaello, I just don’t understand why Trac prefers my pathetically long OpenID instead.

[www.google.com/accounts/o8/id?id=aitoawkwxks0yu8ds1jw9yteckfs0bxwogv8lze]

Uh, I wasn’t thinking OpenRC might be running with a non-GNU userland. Does stat -fc%T file (print human-readable filesystem name of file) have equivalents on *BSD and whoever else may adopt OpenRC?

Looking around, it seems like stat(1) from *BSD takes quite different (an fewer) command line arguments.

[roy.marples.name]

Replying to www.google.com/accounts/o8/id?id=aitoawkwxks0yu8ds1jw9yteckfs0bxwogv8lze:

By the way, I do have a name, that’s Raffaello, I just don’t understand why Trac prefers my pathetically long OpenID instead.

Google doesn't provide any user details from the OpenID.
Although, the OpenID track plugin ought to allow storing localised names to facilitate this.

[roy.marples.name]

Replying to www.google.com/accounts/o8/id?id=aitoawkwxks0yu8ds1jw9yteckfs0bxwogv8lze:

Uh, I wasn’t thinking OpenRC might be running with a non-GNU userland. Does stat -fc%T file (print human-readable filesystem name of file) have equivalents on *BSD and whoever else may adopt OpenRC?

Looking around, it seems like stat(1) from *BSD takes quite different (an fewer) command line arguments.

Yes, the two stat commands are vastly different.

[roy.marples.name]

Replying to www.google.com/accounts/o8/id?id=aitoawkwxks0yu8ds1jw9yteckfs0bxwogv8lze:

Hi Roy,
I prepared a small patch to init.d/bootmisc, adding a few lines to check if a directory it’s considering for wiping is really on tmpfs; if so, no operation occurs.
This assumes safely enough that bootmisc is run upon boot, so any tmpfs filesystem will be empty, no need to hunt for files to delete, and no pointless “Wiping...” messages at the console.

This patch is wrong for several reasons, mainly the last one:

• There are two other fs types for ramdisks in Linux alone
• stat syntax and output varies from system to system
• find on an empty directory is quite fast to start with
• /var/run has entries when you go from multi user to single and back which need to be removed

[www.google.com/accounts/o8/id?id=aitoawkwxks0yu8ds1jw9yteckfs0bxwogv8lze]

Gotcha.

• My ignorance.
• Well... blame the ‘90s?
• I figured, especially on a ramdisk. I was mostly thinking about saving find to parse the quite long list of arguments. Okay, you can laugh now.
• My ignorance.

Okay, I might as well reveal the true intention behind the patch: I use ramdisks quite extensively, even where I shouldn’t (I know /var/{run,tmp} should really be persistent), helped by a configurable init script that creates any directories assumed to persist across reboots.

The thing is, with most directories being always empty, and having a low vertical resolution (800) on my notebook screen, I just wanted to avoid cleaning/wiping messages upon boot (I’m also trying to migrate to the seemingly incomplete init.d/network from the quite verbose init.d/net.*). But the only reasonable way to avoid them seemed to avoid really doing anything...

Actually, writing this explanation gave me a much better (and portable, and more intelligent, and not just plain bad) idea. I might come back later.

Anyway, thank you for the detailed analysis (as opposed to just closing to wontfix).