Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
If tail notices that a file it is following no longer exists (because stat()
fails), it will output any final lines and then close the file. If the read
operation also causes an error, such as when the filesystem is forcefully
unmounted, it closes the file as well, leading to fclose(NULL) and a
segmentation fault.
PR: bin/159750
Submitted by: swills
Approved by: re (kib)
MFC after: 1 week
is in accordance with the information provided at
ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change
Also add $FreeBSD$ to a few files to keep svn happy.
Discussed with: imp, rwatson
trying to open files rather than giving up when it encounters an
error. ENOENT errors are not reported.
As a result, files that are moved away then recreated are not at
risk of being 'lost' to tail. Files that are recreated and
temporarily have unreadable permissions will be shown when they
are fixed.
This behaviour is consistent with the GNU version of tail but
without the verbiage that goes with the GNU version.
This change also fixes error messages accompanying -f and -F.
They no longer report problems with (null)!
MFC after: 3 weeks
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
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.
stat() the file being followed and do a close/reopen if the file has been
renamed and/or rotated. This is damn useful for leaving running on files
in /var/log when newsyslog(8) rotates them.
- Use MAP_FAILED instead of the constant -1 to indicate
failure (required by POSIX).
- Removed flag arguments of '0' (required by POSIX).
- Fixed code which expected an error return of 0.
- Fixed code which thought any address with the high bit set
was an error.
- Check for failure where no checks were present.
Discussed with: bde
- timeval in select loop was depending on not having the remaining time
returned from select(), causing a busy spin on an implementation that
does implement it.
- the err() usage was pretty bogus, some of the error messages had
strerror attached manually and then reattached by err().
