What was the problem encountered before this change? That should be added to the commit message.

With changes like this they have to be mirrored in both src/inotifywait.cpp and src/inotifywatch.cpp .

Ideally we would turn this into a runtime change rather than a buildtime change, so a binary built with ENABLE_FANOTIFY deployed on a system without FANOTIFY built into it's kernel would print something like:

"fanotify not found in this kernel".

So we would have portable binaries.

And we wouldn't really need these ENABLE_FANOTIFY at all. And we would build the whole codebase on each build without excluding/including specific things.

What was the problem encountered before this change? That should be added to the commit message.

Not much of a problem, but I noticed that those flags are listed for fsnotifywait, and not for inotifywait, yet inotifywait did not complain about those, so I wondered whether they both actually handle them. Had to look into the sources to find out, noticed that inotifywait (which builds without ENABLE_FANOTIFY) ignores them, though accepts anyway, which seemed wrong.

With changes like this they have to be mirrored in both src/inotifywait.cpp and src/inotifywatch.cpp .

Indeed, I missed that.

Makes sense about a runtime change, I also wondered whether inotifywait and fsnotifywait are the same binary before looking into it.

So the library should probably attempt to call fanotify_init from inotifytools_init, determine the support, and then behave based on that, including telling the executables whether it is supported? Though it will not be buildable on systems without fanotify. Could also use syscall(2) to check it, but the SYS_fanotify_init value would vary among architectures, so perhaps it is too error-prone to try building without fanotify present at all. Or do you have another way to check it in mind?

Then the difference between inotifywait and fsnotifywait would be just in the defaults (the former defaulting to -I, the latter -- to -F), and there is no need to reject the options at all.

I am skimming the library sources now, but still uncertain how much work it will be. Do you think it would suffice to just add such a check in inotifytools_init, set a global variable, add a function to return it (e.g., int inotifytools_fanotify_available()), and then check it from inotifywait and inotifywatch instead of those compile-time checks, or is there more to it?

What was the problem encountered before this change? That should be added to the commit message.

Not much of a problem, but I noticed that those flags are listed for fsnotifywait, and not for inotifywait, yet inotifywait did not complain about those, so I wondered whether they both actually handle them. Had to look into the sources to find out, noticed that inotifywait (which builds without ENABLE_FANOTIFY) ignores them, though accepts anyway, which seemed wrong.

When fanotify support was merged, there was an idea to rename the whole project to fsnotiftytools as as a user may be using fanotify rather than inotify. We were unsure about this as inotifywait and inotifywatch tools are well known tools that have been around for over a decade I believe. So we ended up with both names.

With changes like this they have to be mirrored in both src/inotifywait.cpp and src/inotifywatch.cpp .

Indeed, I missed that.

Makes sense about a runtime change, I also wondered whether inotifywait and fsnotifywait are the same binary before looking into it.

So the library should probably attempt to call fanotify_init from inotifytools_init, determine the support, and then behave based on that, including telling the executables whether it is supported? Though it will not be buildable on systems without fanotify. Could also use syscall(2) to check it, but the SYS_fanotify_init value would vary among architectures, so perhaps it is too error-prone to try building without fanotify present at all. Or do you have another way to check it in mind?

Then the difference between inotifywait and fsnotifywait would be just in the defaults (the former defaulting to -I, the latter -- to -F), and there is no need to reject the options at all.

I am skimming the library sources now, but still uncertain how much work it will be. Do you think it would suffice to just add such a check in inotifytools_init, set a global variable, add a function to return it (e.g., int inotifytools_fanotify_available()), and then check it from inotifywait and inotifywatch instead of those compile-time checks, or is there more to it?

Sounds good to me.

Here, drafted a version of that. Actually since inotifytools_init already fails on a fanotify_init failure, and expects a decision on whether to use fanotify before it is called (I guess it could be changed, but that would break the API), I ended up not touching the library, but merely removing those compile-time checks, using the executable's basename to decide on the default behaviour at runtime, adjusting the man pages, setting autotools to create symbolic links from fsnotify* to inotify* tools.

It feels like such changes may easily break something, so maybe it is best to not hurry with it. Any thoughts on it, and perhaps some additional adjustment ideas?

I 100% like your thinking @defanor . The main thing is to not break others and all the builds pass, inotifytools runs on all sorts of quirky distros (and some of them are critical things like network switches and stuff) and freebsd, musl normally springs up a surprise, but luckily we have a lot of those covered in our builds, so that being green gives reasonable confidence.

The thing is, you could build on a platform that supports fanotify and deploy on what that doesn't, with containers and whatnot these days, that's more common than ever.

Forgot to include man page changes into the commit, force-pushed them now. fsnotifywatch's additional options used to be in an odd place there, by the way: after events, instead of the OPTIONS section. But here they are merged with the rest of the options.

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
18.8% Duplication

The version of Java (11.0.3) you have used to run this analysis is deprecated and we will stop accepting it soon. Please update to at least Java 17.
Read more here

Catch issues before they fail your Quality Gate with our IDE extension SonarLint