is empty. There doesn't appear to be another easy way to do this.
mobile# mkdir foo
mobile# mkdir foo/bar
mobile# mkdir bar
mobile# find . -empty
./foo/bar
./bar
behave as in GNU find (and of course as described in the manual page
diff included). I think these options would be useful for some people.
Some missing $FreeBSD$ tags are also added.
The patch was slightly modified (send-pr mangling of TABS).
PR: bin/18941
Submitted by: Ben Smithurst <ben@scientia.demon.co.uk>
I added $FreeBSD$ whicle I was here. The patch wasn't usable anymore
due to its age so I adapted it.
PR: bin/3648
Submitted by: Martin Birgmeier <mbirg@austria.ds.philips.com>
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.
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
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)
