Repository: hannobraun/inotify-rs (language: rust)

Issue:
Consider reverting #146 at some point
The compiler [dropped support](https://github.com/rust-lang/rust/issues/62516) for RHEL 5, so #146 can in principle be reverted when the MSRV gets bumped to 1.47.


Discussion / hints:
Thanks for the note!

Do you think there's any pressure to revert that change? To me it seems like it doesn't make any difference in practical terms. But I'm happy to change it back, if it's causing problems for anyone.
Nope, it's just cleaning up a workaround that's no longer needed. The two extra syscalls probably don't matter, but there's no point in having them. I filed this to keep track of it.
Makes sense, thanks again!

Fix patch:
diff --git a/src/inotify.rs b/src/inotify.rs
index f85fb1c..bd21e7b 100644
--- a/src/inotify.rs
+++ b/src/inotify.rs
@@ -16,9 +16,7 @@ use std::{
 use inotify_sys as ffi;
 use libc::{
     F_GETFL,
-    F_SETFD,
     F_SETFL,
-    FD_CLOEXEC,
     O_NONBLOCK,
     fcntl,
 };
@@ -84,34 +82,29 @@ impl Inotify {
     /// [`IN_CLOEXEC`]: ../inotify_sys/constant.IN_CLOEXEC.html
     /// [`IN_NONBLOCK`]: ../inotify_sys/constant.IN_NONBLOCK.html
     pub fn init() -> io::Result<Inotify> {
-        // Initialize inotify and set CLOEXEC and NONBLOCK flags.
-        //
-        // NONBLOCK is needed, because `Inotify` manages blocking behavior for
-        // the API consumer, and the way we do that is to make everything non-
-        // blocking by default and later override that as required.
-        //
-        // CLOEXEC prevents leaking file descriptors to processes executed by
-        // this process and seems to be a best practice. I don't grasp this
-        // issue completely and failed to find any authoritative sources on the
-        // topic. There's some discussion in the open(2) and fcntl(2) man pages,
-        // but I didn't find that helpful in understanding the issue of leaked
-        // file descriptors. For what it's worth, there's a Rust issue about
-        // this:
-        // https://github.com/rust-lang/rust/issues/12148
         let fd = unsafe {
-            let fd = ffi::inotify_init();
-            if fd == -1 {
-                return Err(io::Error::last_os_error());
-            }
-            if fcntl(fd, F_SETFD, FD_CLOEXEC) == -1 {
-                return Err(io::Error::last_os_error());
-            }
-            if fcntl(fd, F_SETFL, O_NONBLOCK) == -1 {
-                return Err(io::Error::last_os_error());
-            }
-            fd
+            // Initialize inotify and pass both `IN_CLOEXEC` and `IN_NONBLOCK`.
+            //
+            // `IN_NONBLOCK` is needed, because `Inotify` manages blocking
+            // behavior for the API consumer, and the way we do that is to make
+            // everything non-blocking by default and later override that as
+            // required.
+            //
+            // Passing `IN_CLOEXEC` prevents leaking file descriptors to
+            // processes executed by this process and seems to be a best
+            // practice. I don't grasp this issue completely and failed to find
+            // any authoritative sources on the topic. There's some discussion in
+            // the open(2) and fcntl(2) man pages, but I didn't find that
+            // helpful in understanding the issue of leaked file descriptors.
+            // For what it's worth, there's a Rust issue about this:
+            // https://github.com/rust-lang/rust/issues/12148
+            ffi::inotify_init1(ffi::IN_CLOEXEC | ffi::IN_NONBLOCK)
         };
 
+        if fd == -1 {
+            return Err(io::Error::last_os_error());
+        }
+
         Ok(Inotify {
             fd: Arc::new(FdGuard {
                 fd,


Test patch: