the cumulative exit status being overwritten when directory permissions
were being set. This was particularly bad when called from mv(1) to
perform a cross-device move as the original files were deleted even if
the copy failed.
Reported by: Slaven Rezic <slaven.rezic@berlin.de>
Patch by: bde
PR: 42789
hack, thereby allowing future extensions to the structure (e.g., for extended
attributes) without rebreaking the ABI. FTSENT now contains a pointer to the
parent stream, which fts_compar() can then take advantage of, avoiding the
undefined behavior previously warned about. As a consequence of this change,
the prototype of the comparison function passed to fts_open() has changed
to reflect the required amount of constness for its use. All callers in the
tree are updated to use the correct prototype.
Comparison functions can now make use of the new parent pointer to access
the new stream-specific private data pointer, which is intended to assist
creation of reentrant library routines which use fts(3) internally.
Not objected to in spirit by: -arch
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
Fix the case:
cp file nonexistent/
which create nonextstent as file while trailing slash clearly indicates
that nonexistent must be a directory.
Also fix the case:
cp file1 file2/
which should produce error.
o __P has been reoved
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.
Approved by: arch@, new style(9)
circumstances. This is a reworked version of the same fix, that does
not have this defect, and which fixes some style bugs at the same time.
Bug reported and fix reviewed by: bde
the !(pflag && setfile()) case for regular files unless the copy is
owned by the same user and group. These bits have already been lost
(or never gained) in the correct way. The code didn't actually lose
the bits; it depended on them being lost already (apparently in all
cases) and attempted to gain them as necessary, but it often gained
them (and sometimes collateral bits) when wrong:
- pflag && setfile() == 0 case (i.e., for a successful cp -p):
setfile() copies all the attributes as correctly as possible (as
specified by POSIX), and we sometimes messed up the up the mode by
setting it again. Also, if the file is immutable, then setting the
mode again gave spurious errors (PR 20646).
- !pflag case. If the target is created, POSIX requires it to not
have the set[ug]id bits, but we sometimes copied them from the source.
If the target already exists, POSIX requires its mode to be unchanged,
but we sometimes copied the whole mode from the source.
PR: 20646
MFC after: 4 weeks
statement if blocks[*] when the else could be ambiguous, not defaulting
to int type and removal of some unused variables.
[*] This is explicitly allowed by style(9) when the single statement
spans more than one line.
Reviewed by: obrien, chuckr
for regular files. This fixes recent breakage of cp'ing from /dev/zero.
/dev/zero doesn't support mmap(), but the device driver mmap routines are
not called for mapping 0 bytes, so the error was not detected. mmap()
can't even be used for cp'ing special files that support mmap(), since
there is general way to determine the file size.
This should calm down attempts to `cp -p' to a nfs mount or some other
filesystem that doesn't accept flags or all combinations of flags.
It will warn if it fails to change flags though.
