Dear Maintainer,

If
  ~/uwu$ echo tupa > t/a/i/l/zupa
then
  $ tail -F ~/uwu/t/a/i/l/zupa
  tupa
and when
  ~/uwu$ mv t q; mkdir -p t/a/i/l; echo trużpan > t/a/i/l/zupa
nothing changes.

Naturally,
  $ cat /proc/$(pgrep tail)/fdinfo/4
  pos:    0
  flags:  00
  mnt_id: 15
  ino:    2075
  inotify wd:2 ino:20e117 sdev:71 mask:c06 ignored_mask:0 fhandle-bytes:c fhandle-type:1 f_handle:941d177517e1200000000000
  inotify wd:1 ino:20e116 sdev:71 mask:784 ignored_mask:0 fhandle-bytes:c fhandle-type:1 f_handle:5d7d142316e1200000000000
and nothing actually changed with what I assume are watches for
~/uwu/t/a/i/l/zupa and ~/uwu/t/a/i/l, and if you muck around with it
(by killing q/a/i/l/zupa or whatever) so much tail says it falls back
to polling, then it works again.

I don't think actually generalising tail -F is possible with linux's
(d|i|fs)notify systems. Or that it's worth-while to do so for the
specified use-case of log rotation.

OTOH, this is NOT documented. And neither is ---disable-inotify,
which is needed to work around some Linux bugs (like #1039488).

Please (a) document this behaviour, and (b) document ---disable-inotify
(for which, funnily enough, the only two results on DCO are coreutils
 and rust-coreutils:
https://codesearch.debian.net/search?q=---disable-inotify&perpkg=1
 )
as fixing it.

Best,
наб