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
occurrences of "/" in the argument list. This corresponds to Enhancement
Request Number 5 in the Austin Group TC2 Aardvark's XCU Defects Report
(<URL:http://www.opengroup.org/austin/aardvark/finaltext/xcubug.txt>).
Further discussion is available in the Austin Group mailing list archives
(<URL:http://www.opengroup.org/austin/mailarchives/>, "Defect in XCU rm")
and for Austin Group members, in the Austin Group Interpretations archive
(<URL:http://www.opengroup.org/austin/interps/>, AI-019)
This commit makes that check conditional on !POSIXLY_CORRECT, since it
is not strictly correct according to the current version of the standard
(but is expected to be correct according to the next version, and has
already been adopted by Solaris).
o When fts_read() cannot stat the file, it can't be unlinked. At
that case, don't display error message when -f flag is used.
Obtained from: bde
PR: kern/16815, bin/35842
Reported by: kuriyama, Aleksandr A. Babaylov <.@babolo.ru>
do only unlink the file if we could indeed overwrite the file.
Old behaviour: rm -P /tmp/foo (foo mode 0444) would NOT overwrite foo,
but still delete it (with a warning: rm: foo: Permission denied)
New behaviour: Just the EPERM warning, but no deletion
Reviewed by: bde
rm_overwrite() (for rm -P).
2. Print the file name in the error message for (fatal) malloc() failures
in rm_overwrite(). I first thought that malloc() failures should be
non-fatal since they don't prevent proceeding the the next file, but
making them non-fatal would normally give too much output for rm -Pr
on a large tree in the unlikely event that even one occurs, since the
malloc()ed amounts are usually the same. Just print the file name since
the malloc()ed amounts are not always the same and it doesn't hurt to
know where rm was when it quit.
Submitted by: guido ((1) and original version of (2))
arg 2 to err() and friends, and warnings are promoted to errors.
This allows the following revisions to be reverted:
rev 1.39 src/bin/cp/cp.c
rev 1.26 src/bin/chmod/chmod.c
rev 1.40 src/bin/rm/rm.c
The following revisions can already be reverted, because they were
already covered by WFORMAT=0:
rev 1.8 src/bin/ls/lomac.c
rev 1.63 src/bin/ls/ls.c
rev 1.8 src/bin/ps/lomac.c
rev 1.34 src/bin/rcp/rcp.c
Move group_from_gid to grp.h
Remove from stdlib.h
Make the prototypes match the code
Fix rm and mv to include new files.
NetBSD has these defined in those files, and others too that I've not
done.
Approved by: terminal room kabal
Reviewed by: jhb, phk
o Old-style K&R declarations have been converted to new C89 style
o register has been removed
o prototype for main() has been removed (gcc3 makes it an error)
o int main(int argc, char *argv[]) is the preferred main definition.
o Attempt to not break style(9) conformance for declarations more than
they already are.
(which somehow now seems to be the default for compiling -current).
This error popped up while doing a PicoBSD cross-compile on a 4.3-ish system,
it may well be that there are other apps which have similar problems,
but I did not spot them as they are not included in my picobsd config.
Whether adding prototypes for main() is the correct solution or not
I have no idea, a request to -current on the matter went basically
unanswered. Those who have better ideas are welcome to back this out
and replace it with the correct fix.
