On 30/10/2026 03:18, Collin Funk wrote:
diff --git a/NEWS b/NEWS
index 4e2c1d65d..f52f19a89 100644
--- a/NEWS
+++ b/NEWS
@@ -131,6 +131,12 @@ GNU coreutils NEWS -*-
outline -*-
if events arrived faster than tail could process them.
[bug introduced in coreutils-7.5]
+ 'tail --follow' no longer sizes inotify event buffers based on the length of
+ file operands. This would cause it to exit with an inotify error when an
+ event occurred on a large file, e.g., creating or modifying a file, in one of
+ the directories containing the operands.
+ [bug introduced in coreutils-7.5]
I'd change this NEWS to:
'tail -F' no longer fails with "error reading inotify event" when a separate
file with a longer name is created, removed, or renamed in the directory
of a followed file.
[bug introduced with inotify support added in coreutils-7.5]
I'd also change the reference in the previous inotify fix
to using the same inotify specific wording.
+
'timeout --signal=ALRM -k' again honors the -k option.
Similarly 'timeout --signal=CHLD' no longer reports "No child processes",
or hangs as it has done since coreutils-8.27, once the command exits.
diff --git a/src/tail.c b/src/tail.c
index 945e129a4..6755d61c1 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -1534,9 +1534,6 @@ tail_forever_inotify (int wd, struct File_spec *f, int
n_files,
bool found_unwatchable_dir = false;
bool no_inotify_resources = false;
struct File_spec *prev_fspec;
- idx_t evlen = 0;
- char *evbuf;
- idx_t evbuf_off = 0;
*parent_by_namep = NULL;
@@ -1569,10 +1566,6 @@ tail_forever_inotify (int wd, struct File_spec *f, int n_files,
{
if (!f[i].ignore)
{
- idx_t fnlen = strlen (f[i].name);
- if (evlen < fnlen)
- evlen = fnlen;
-
f[i].wd = -1;
if (follow_mode == Follow_name)
@@ -1680,8 +1673,9 @@ tail_forever_inotify (int wd, struct File_spec *f, int
n_files,
if (debug)
error (0, 0, "%s", _("using notification mode"));
- evlen += sizeof (struct inotify_event) + 1;
- evbuf = ximalloc (evlen);
+ idx_t evbuf_off = 0;
+ idx_t evlen = sizeof (struct inotify_event) + NAME_MAX + 1;
+ char *evbuf = ximalloc (evlen);
This static value might be too much or too little.
Hmm I see the inotify man page states the above is sufficient.
I was thinking of caching fpathconf(dirfd, _PC_NAME_MAX) if available,
but I suppose one could have other file systems (bind) mounted
in the parent dir, in which case the current FS limit wouldn't be appropriate.
Also I was worried about the portability of NAME_MAX
(which is not available on Solaris for example).
However NAME_MAX should be available where inotify is (Linux/FreeBSD).
I'd add a short comment about that though. Something like.
/* NAME_MAX covers that max length of all file systems
that might be mounted in the parent dir, and the define
should be available any where that inotify is. */
diff --git a/tests/tail/inotify-long-name.sh b/tests/tail/inotify-long-name.sh
+cleanup_() { kill "$pid" 2>/dev/null; wait "$pid" 2>/dev/null; pid=; }
+
+# Make sure we can create a long file name.
+long_name=$(printf '%0255d' | tr '0' 'a') || framework_failure_
+touch "$long_name" || skip_ 'cannot create long file name'
+rm -f "$long_name" || framework_failure_
+
+# Create an empty file to tail.
+touch file || framework_failure_
The cleanup_ definition could be moved to here
to avoid calling it in the above framework_failures.
+
+# Now tail it and make sure we are using notification mode.
+timeout 60 tail --debug -F file >out 2>&1 & pid=$!
+tail_re='tail: using notification mode' retry_delay_ check_tail_output .1 7 ||
+ { cat out; cleanup_; skip_ 'tail did not switch to notification mode'; }
The explicit cleanup_ call above is redundant,
and will result in it being called twice upon skip.
thanks,
Padraig
