ast@cs.vu.nl (Andy Tanenbaum) (08/17/90)
From: Andy Tanenbaum <ast@cs.vu.nl>
While studying the P1003.2 description of the 'cp' utility, I ran into an
ambiguity. In paragraph 4.13.2 (description), line 1985 & 1996-2000, it says:
(1) If the destination path exists:
(b) If the permissions of the file to which the destination path
refers to do not permit writing, actions are performed equivalent to
the unlink() #5.5.1[POSIX.1] function call using destination as the
path argument, and, if this fails for any reason...
In paragraph 4.13.3 (options), next page, lines 2010 & 2011 says:
-f For each existing destination pathname, remove it and create a new
file, without prompting for confirmation regardless of its permissions
Now, I believe that the description should say:
(b) If the permissions of the file to which the destination path
refers to do not permit writing, or if the -f option is specified, ...
to be consistent, but then "cp -f" would snap any existing links to the
destination file, and even change the destination file mode, owner and group
(without a -p being specified), while "cp" wouldn't.
Example:
-rw-r--r-- 1 user1 group1 srcfile
-rw-rw-rw- 2 user2 group2 dstfile
If user3 (group3) invokes cp srcfile dstfile, then the dstfile's mode, owner,
group and links do not change. However, if cp -f srcfile dstfile is invoked,
then the dstfile becomes:
-rw-r--r-- 1 user3 group3 dstfile
Now, this behavior might be correct, but is this effect really intended by
P1003.2? Possibly, the user that wish to replace the dstfile entirely (as
opposed to overwriting it) should use rm BEFORE calling cp, and the -f option
should be used only to suppress interaction with the user.
Maybe draft 10 clarifies the situation?
Vincent Archer | Email:archer%segin4.segin.fr@relay.prime.com
"People that are good at finding excuses are never good at anything else"
(Posted by Andy Tanenbaum because Vincent does not have USENET access.)
Volume-Number: Volume 21, Number 41djm@eng.umd.edu (David J. MacKenzie) (08/18/90)
From: djm@eng.umd.edu (David J. MacKenzie)
In article <439@usenix.ORG> ast@cs.vu.nl (Andy Tanenbaum) writes:
(1) If the destination path exists:
(b) If the permissions of the file to which the destination path
refers to do not permit writing, actions are performed equivalent to
the unlink() #5.5.1[POSIX.1] function call using destination as the
path argument, and, if this fails for any reason...
Now, this behavior might be correct, but is this effect really intended by
P1003.2? Possibly, the user that wish to replace the dstfile entirely (as
opposed to overwriting it) should use rm BEFORE calling cp, and the -f option
should be used only to suppress interaction with the user.
Maybe draft 10 clarifies the situation?
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.
--
David J. MacKenzie <djm@eng.umd.edu> <djm@ai.mit.edu>
Volume-Number: Volume 21, Number 42caywood@teb.larc.nasa.gov (John Caywood) (09/07/90)
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
cowan@marob.masa.com (John Cowan) (09/07/90)
From: cowan@marob.masa.com (John Cowan) In article <490@usenix.ORG> caywood@teb.larc.nasa.gov (John Caywood) writes: >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. The difference between unlinking before opening and opening with O_TRUNC is, of course, that the former course of action can change the file's owner, group, and mode settings, whereas the latter course of action cannot. -- cowan@marob.masa.com (aka ...!hombre!marob!cowan) e'osai ko sarji la lojban Volume-Number: Volume 21, Number 90
jtkohl@MIT.EDU (John T Kohl) (09/07/90)
From: jtkohl@MIT.EDU (John T Kohl) In article <490@usenix.ORG> caywood@teb.larc.nasa.gov (John Caywood) writes: > 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. Consider the case where the file in question has several hard links from different filenames. O_TRUNC is not equivalent to unlink. -- John Kohl <jtkohl@ATHENA.MIT.EDU> or <jtkohl@MIT.EDU> Digital Equipment Corporation/Project Athena (The above opinions are MINE. Don't put my words in somebody else's mouth!) Volume-Number: Volume 21, Number 88