o When stat(2) fails (i.e. the file has been moved) there's no new
file with the same name yet, so keep showing the file that's open.
This yields the same behaviour as -f, for which we don't stat(2).
o When a new file with the same name has been created (i.e stat(2)
succeeds but the inode or device numbers differ from the opened
file), show any new lines in the opened file (i.e. the old or
rotated file) before reopening the new file.
These changes fix the observed behaviour that tail(1) doesn't show
the very last lines of the rotated (log) files.
PR: bin/101979
Tested by: Jos Backus <jos@catnook.com>
MFC after: 2 months
after allocating a new buffer. This bug caused `tail -r < /dev/null'
to core dump when the `J' malloc option is set, and also affected
any other input that was an exact multiple of 128k.
during we show the first file's tail. Instead of:
tarsier% tail -f 1 2
==> 1 <==
foo
bar
==> 2 <==
bar
foo
==> 2 <==
bar2
foo2
Now with this change, we have:
tarsier% tail -f 1 2
==> 1 <==
foo
bar
==> 2 <==
bar
foo
bar2
foo2
While I'm there, move a comment to where it should belong to. Also,
const'ify the "last" static because we will never need to change the
contents it points to.
MFC After: 1 week
files is usually the first direct block pointer. Since FreeBSD does
automatic block reallocation to reduce filesystem fragmentation, the
file being tailed can be relocated to different blocks 'on-the-fly',
making the check for st_rdev unreliable. The result of this bug is
tail -F pseudo-randomnly thinking the file was rotated when it wasn't,
and as a result, spews out the entire file trying to catch up.
MFC after: 3 days
renames/rotations) only detected cases where the file itself was
moved or deleted. If part of the path to the file (or a symlink
in the path) was changed instead, tail would not notice.
Fix this by ensuring that we stat the path at least once every
second in the -F case to check for changes. We still use kqueue
when possible to inform us quickly when the file has changed.
PR: bin/24955
Submitted by: Maxim Konovalov <maxim@macomnet.ru>
MFC after: 1 week
long -> off_t
strtol -> strtoll
fseek -> fseeko
NOTE: that fseek not works for >long offsets files per POSIX:
[EOVERFLOW] For fseek( ), the resulting file offset would be a value which
cannot be represented correctly in an object of type long.
fseeko(file_size, SEEK_SET) -> fseek(0L, SEEK_END)
1) File may grows between operations, so fseeko to file_size may miss
2) 0L, SEEK_END is the same code using in tail in all other places
1) really check for size overflow by checking negative value.
2) since mmap() not support files over INT_MAX size, add check for it
until either mmap() will be fixed or tail will be rewritted to handle
large files alternatively.
3) replace fseek(... file_size, SEEK_SET) with fseek(... 0L, SEEK_END)
to avoid off_t -> long cast
4) Use exit() if file is too big instead of warning and wrong logic
afterwards.
filesystem not being kq-aware), then fall back to using sleep. This
allows tail to work with NFS filesystems again without chewing up CPU time.
When given the -F flag, resort to sleep/stat after the file was moved
or deleted. This allows a window where the file being tailed does not
exist at all, which is typically the case during log rotation. Switch
back to using kq (if possible) after the file is reopened.
