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
Note: tcsh(1) has a MK_TCSH=no test, so this should be a separate
package, which requires pre-install/post-install scripts, to be
added later.
Sponsored by: The FreeBSD Foundation
edition 2013. No need anymore to disable the protection if one set
the POXILY_CORRECT environment variable.
Reviewed by: imp
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D4092
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
fflag to ignore fts_read errors, but stop deleting from that directory
because no further progress can be made.
When building a kernel with a high -j value on a high core count
machine, during the cleanobj phase we can wind up doing multiple rm
-rf at the same time for modules that have subdirectories. This
exposed this race (sometimes) as fts_read can return an error if the
directory is removed by another rm -rf. Since the intent of the -f
flag was to ignore errors, even if this was a bug in fts_read, we
should ignore the error like we've been instructed to do.
directory entry then use the struct stat from that instead of doing
it again, and skip the rm_overwrite() call if fts_read() indicated
that the entry couldn't be a regular file.
Obtained from: OpenBSD
MFC after: 1 week
that the file we have opened is the one we expected. Also open in
non-blocking mode to avoid a potential hang with FIFOs.
Obtained from: NetBSD via OpenBSD
For these simple utilities, it doesn't harm to make all global variables
static. In fact, this allows the compiler to perform better forms of
optimisation and analysis.
Formerly, this tried to clear the flags on the symlink's target
instead of the symlink itself.
As before, this only happens for root or for the unlink(1) variant of rm.
PR: bin/111226 (part of)
Submitted by: Martin Kammerhofer
Approved by: ed (mentor)
MFC after: 3 weeks
instead of removing the file and issue a warning about
the removal, do not do any operation at all in case -P
is specified when the dinode has hard links.
With -f and -P specified together, we assume that the
user wants rm to overwrite the contents of the file
and remove it (destroy the contents of file but leave
its hard links as is).
The reason of doing it this way is that, in case where
a hard link is created by a malicious user (currently
this is permitted even if the user has no access to the
file). Losing the link can potentially mean that the
actual owner would lose control completely to the user
who wants to obtain access in a future day.
Discussed with: Peter Jermey
is hard links. Overwritting when links > 1 would cause data
loss, which is usually undesired.
Inspired by: discussion on -hackers@
Suggested by: elessar at bsdforen de
Obtained from: OpenBSD
earlier, and more gracefully. Previously, this combination would be
ignored early in the code where permissions are tested and fail later
with a very unhelpful "permission denied" error.
Instead, test for this flag in the same block that generates the
"override?" messages for read-only files, but instead of trying
to guess what the user has in mind, generate an error and exit.
Update the man page to reflect this new behavior.
Not objected to by: freebsd-hackers@
removing directories or if more than 3 files are listed in the
command line.
This feature is intended to provide a safe net but not being too
annoying like having "rm -i" for every deleting operations, and
is generally good for both newbies and power users, preventing
them from being so easily run into ``rm -rf /'', ``rm -rf *''
and so forth.
Originally implemented by Matthew Dillon for DragonFly, plus
some improvements done by various DragonFly contributors.
Approved by: murray (mentor; the original dillon's version)
Discussed with: des
Obtained from: DragonFly's bin/rm/
rm.c rev. 1.4 - 1.8
rm.1 rev. 1.3 - 1.4
MFC After: 1 month
