| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
PR: docs/9255
Submitted by: Christian Weisgerber <naddy@bigeye.rhein-neckar.de>
|
|
|
|
| |
Obtained from: OpenBSD
|
| |
|
|
|
|
|
| |
Don't format paragraphs manually (new sentences not beginning on new
lines give hard-formatted line breaks).
|
| |
|
| |
|
|
|
|
| |
Broken in: previous commit
|
| |
|
|
|
|
|
| |
The sort option make it possible to build the locate
database without large (usually 20-100MB) temp files.
|
|
|
|
|
|
|
|
|
|
|
| |
execvp() in the child branch of a vfork(). Changed to use fork()
instead.
Some of these (mv, find, apply, xargs) might benefit greatly from
being rewritten to use vfork() properly.
PR: Loosely related to bin/8252
Approved by: jkh and bde
|
|
|
|
|
| |
Correct bug in the inverse operator optimisation code which caused segv
on ! without a following expression.
|
| |
|
|
|
|
|
|
| |
NUL at the end of the path.
Inspired by: OpenBSD's changes in this area by theo de raadt
|
|
|
|
|
| |
Submitted by: Josh Gillam <josh@quick.net>
PR: docs/6642
|
|
|
|
| |
the default.
|
|
|
|
|
|
|
|
|
| |
doesn't know about getvfsbyname() and the vfsconf structure. This
disables the -fstype option if compiled with a pre-processor that
defines __NetBSD__. With the FreeBSD built pre-processor, find can only
be built with the FreeBSD libc. So when running with a NetBSD kernel,
FreeBSD's libc will have to return ENOSYS for things that NetBSD
doesn't support. That's life in a hybrid world.
|
|
|
|
|
| |
PR: 5171
Submitted by: Dmitrij Tejblum <tejblum@arc.hq.cti.ru>
|
|
|
|
|
|
| |
are extensions along with the previous list of primaries.
Suggested by: bde
|
|
|
|
|
|
|
| |
can gather from the Posix spec that I have (which is very old)
all one character options are extensions to Posix.
PR: docs/4701
|
| |
|
|
|
|
|
|
|
| |
in question. This change and the fts changes should be merged into 2.2-stable
as soon as they are vetted in -current. This should allow cleaning of files
in /tmp to be reneabled.
Obtained from: OpenBSD
|
| |
|
| |
|
|
|
|
|
|
| |
Closes PR docs/3612.
Submitted by: Josh Gilliam <soil@quick.net>
|
|
|
|
|
| |
PR: 3472
Submitted by: Josh Gilliam <soil@quick.net>
|
|
|
|
| |
posix standard on the topic.
|
|
|
|
| |
Submitted by: Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru>, PR#3076
|
|
|
|
| |
understand whiteouts (FTS_W from fts()).
|
|
|
|
|
|
|
|
| |
kind of expressions caused a dereferencation of an uninitialized malloc
area, yielding wrong expression evaluation at best, and core dumps at
worst (malloc.conf -> AJ):
find ... ! \( expr1 ! expr2 \) ...
|
| |
|
|
|
|
|
|
|
|
| |
This error results from changing the name for the msdos file system
from "pcfs" to "msdos". Close PR #1105
submitted by: Thomas Wintergerst <thomas@lemur.nord.de>,
Slaven Rezic <eserte@cs.tu-berlin.de>
|
|
|
|
|
|
|
|
| |
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
|
|
|
|
| |
"cd /tmp; find . -mtime +7 -delete" is excessively noisy.
|
|
|
|
|
|
| |
user-immutable files.
Requested by: ache
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
goes to a fair degree of trouble to enable something like this to
be safe: cd /tmp && find . -mtime +7 -delete
It removes both files and directories. It does not attempt to remove
immutable files (an earlier version I showed to a few people did a chflags
and tried to blow away even immutable files. Too risky..)
It is thought to be safe because it forces the fts(3) driven descent to
only do "minimal risk" stuff. specifically, -follow is disabled, it does
checking to see that it chdir'ed to the directory it thought it was
going to, it will *not* pass a pathname with a '/' character in it to
unlink(), so it should be totally immune to symlink tree races. If it runs
into something "fishy", it bails out rather than blunder ahead.. It's better
to do that if somebody is trying to compromise security rather than risk
giving them an opportunity. Since the unlink()/rmdir() is being called
from within the current working directory during the tree descent, there
are no fork/exec overheads or races.
As a side effect of this paranoia, you cannot do a
"find /somewhere/dir -delete", as the last argument to rmdir() is
"/somewhere/dir", and the checking won't allow it. Besides, one would use
rm -rf for that case anyway. :-)
Reviewed by: pst (some time ago, but I've removed the immutable file
deletion code that he complained about since he last saw it)
|
|
|
|
| |
Obtained from: A Quarter Century of UNIX, Peter H. Salus, page 41
|
| |
|
|
|
|
|
|
|
| |
specified.
Not fixed: specification of large uids and gids; silent truncation of
unrepresentable values.
|
|
|
|
| |
Submitted by: Wolfram Schneider <wosch@freebsd.first.gmd.de>
|
|
|
|
|
|
|
| |
[ Find to a file vs. to stdout ] produces different output because find
does not flush stdout when doing a -print.
Submitted by: Jeffrey Hsu <hsu@freefall.freebsd.org>
|
|
|
|
| |
which is no longer bogusly installed in /usr/include.
|
| |
|
|
|
|
|
| |
do `find some-nasty-expression -print0 | perl -n0e unlink' and have all
the files actuallly get deleted. (Using `xargs' and `rm' is not safe.)
|
|
|
|
|
|
|
| |
a find -foo -o -bar would behave like find -bar. The same for -a
This broke (among others) ./etc/security.
Obtained from: NetBSD
|
|
|