🚀 go-pugleaf

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 42

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

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

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

From: barmar@think.uucp (Barry Margolin)

In article <496@usenix.ORG> cowan@marob.masa.com (John Cowan) writes:
>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.

Does POSIX have the O_CREAT mode flag?

This is related to my favorite complaint as a user of an unusual NFS
server.  We have Symbolics Lisp Machines that run their NFS server, and the
Symbolics file system has files with version numbers.

When a client is opening an existing file for output there are two ways it
can do it.  It can call the NFS Create entry, or it can call NFS Lookup
followed by NFS SetAttr to set the length to 0.  These two operations have
equivalent results with a Unix server (although the second requires more
network operations), but the Symbolics server treats the Create operation
as a request to create a new version of the file.  I thought of having
SetAttr create a new version when asked to truncate to zero length, but
this wouldn't help because the client already has a file handle on the
previous version, and it wouldn't be correct to change the association
between a file handle and the actual file (a second client might be using
that file handle).

The SunOS client uses the Create method, and most of our NFS clients are
Suns, so it's not a major problem.  However, Ultrix 3.1 uses the
Lookup/SetAttr method.  We complained to DEC a year or two ago about this
but they were unsympathetic.  The most surprising thing, to me, about this
lack of sympathy is that DEC's proprietary OS, VMS, has version numbers, so
I would imagine that this would be a problem for Ultrix clients using VMS
servers.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

Volume-Number: Volume 21, Number 94