Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!usenix!std-unix From: caywood@teb.larc.nasa.gov (John Caywood) Newsgroups: comp.std.unix Subject: Re: Query about P1003.2 'cp' utility Message-ID: <490@usenix.ORG> Date: 6 Sep 90 20:26:00 GMT References: <439@usenix.ORG> Sender: std-unix@usenix.ORG Organization: NASA Langley Research Center, Hampton, VA USA Lines: 31 Approved: jsq@usenix.org (Moderator, John Quarterman) X-Submissions: std-unix@uunet.uu.net From: caywood@teb.larc.nasa.gov (John Caywood) In Volume 21, Number 42, djm@eng.umd.edu (David J. MacKenzie) writes: > In draft 10, cp never ever unlinks files. > In draft 10, all -f does in cp is turn off a previous -i. > I'm going to object to this on the FSF ballot; I think -f should make > it unlink (unconditionally), like it does for mv, ln, and rm, or else > not be specified at all in the standard, since it's not existing > practice. Based on this article, I was about ready to submit an objection in support of the above. On closer inspection, however, I think the objection is nullified by an earlier clause: (3) If source_file exists.... (a) If dest_file exists.... [1] If -i is in effect.... [2] If dest_file isn't writable.... [3] A file descriptor shall be obtained by performing actions equivalent to the POSIX.1 open() function call using dest_file as the path argument, and the bitwise inclusive OR of O_WRONLY and O_TRUNC as the oflag argument. I take this to mean that, no, cp doesn't unlink an existing file, but it truncates it upon opening under these conditions. Consequently, yes, djm is correct, cp doesn't unlink. I don't understand, though, why opening with O_TRUNC isn't equivalent. John Caywood, balloting .2 on behalf of NASA Langley Research Center Volume-Number: Volume 21, Number 84