This includes adding support for ACLs into cp(1) and mv(1) userspace
utilities.
For mv(1), if _PC_ACL_EXTENDED is in effect for the source AND destination
operands, the destination file's ACLs shall reflect the source.
For cp(1), if _PC_ACL_EXTENDED is in effect for both source and destination
operands, and -p has been specified, the ACLs from the source shall be
preserved on the destination.
MFC after: 1 month
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)
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.
printed a bogus warning with a stale errno if write() returns a short
count. Now we continue copying. We still print a bogus warning if
write() returns an "impossible" short count of 0.
- Use MAP_FAILED instead of the constant -1 to indicate
failure (required by POSIX).
- Removed flag arguments of '0' (required by POSIX).
- Fixed code which expected an error return of 0.
- Fixed code which thought any address with the high bit set
was an error.
- Check for failure where no checks were present.
Discussed with: bde
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.
documented and is incompatible with gnu cp. It has very few good effects
(it recovers some disk space) and many bad ones:
- special files are unlinked after certain errors.
- the data may not be recoverable if the source is a special file or fifo.
- unlinking destroys the target attributes as well as the target data.
- unlinking doesn't actually remove the target data if the target is multiply
linked.
