On 6/4/21 2:03 PM, Niall Douglas via Boost wrote:
On 04/06/2021 10:12, Andrey Semashev via Boost wrote:
My stance on this is that Boost.Filesystem must be built on a system with kernel headers matching or older than the systems that will run the binary. This matches the same requirements for Windows. I don't support configs with headers newer than runtime kernel.
It's trivially easy to do a runtime check for statx kernel support and fall back on older syscalls if needed.
This is LLFIO doing so, and it works on Linux kernel 2.6:
https://github.com/ned14/llfio/blob/develop/include/llfio/v2.0/detail/impl/p...
The code you pointed to is not what I would call trivial. There are quite a few places where statx is used in Boost.Filesystem, in some places exclusively (i.e. there is no fallback). I could add a runtime check, but I definitely don't want that check to happen on every call. This means the result must be stored globally in a thread-safe manner. Then there are other syscalls, on Linux and other systems, should I also add runtime checks for those? All that to support what I consider improperly configured systems. It just doesn't look like a worthwhile effort while I have other things to do, including in Boost.Filesystem too.