Bedrock hijack makes some directories and its files incompatible with d_type from readdir

[spiwocoal]

I was trying out a Bedrock install on top of my Void Linux system when I noticed a program I regularly use suddenly stopped working. I started to dig into the program to determine what went wrong (I ended up just compiling the program myself with debug symbols and just debugging it line by line) and I discovered that the problem was that, when searching for config files, it was using readdir to filter out everything that didn't have a d_type of DT_REG or DT_LNK, and for some reason, all my files under the /etc/ directory, were returning a d_type of DT_UNKNOWN. After a PR to the developer of the program to fallback to lstat if any file has a d_type of DT_UNKNOWN, I decided to test with different system configurations as the one I was using was not a common one (Void Linux with musl libc, using btrfs on my disks), and so to make sure this was indeed something caused by Bedrock and not by some other external factor.

I ended up checking the following on my Thinkpad T440s:

• Void Linux (musl) + btrfs
• Void Linux (glibc) + btrfs
• Void Linux (glibc) + XFS
• Void Linux (glibc) + ext4
• Arch Linux + ext4

On each of those configurations, the problem persisted, so my conclusion is that this is indeed a Bedrock issue, though I am not sure what could be the reason. I am willing to test this out with some more configurations, but I think this should be enough.

[paradigm]

Bedrock mounts a FUSE filesystem on /etc. For things like this it's supposed to pass through data from the backing filesystem, but skimming the relevant part of its source it doesn't seem to be making use of d_type anywhere. The per-dirent part of the libfuse API is that filler() function to which we're consistently passing NULL for the third parameter rather than anything interesting. Skimming the relevant part of libfuse's source I think we should be passing a struct stat pointer there with d_type set. (We're not using FUSE_READDIR_PLUS).

Given man 3 readdir indicates

All applications must properly handle a return of DT_UNKNOWN.

I can't justify prioritizing this enough to get to it for a number of weeks, but I do hope to fix this once current time pressures relax. There's a few other small fixes I'm queueing up for point fix in February - I'll see if I can ensure this makes it in then.

Given your excellent description of the issue, I suspect you may have the background to give that a try yourself; if so you're welcome to give it a go.

[spiwocoal]

I see then, no worries though. I'll see if I can give it a try!