Overwriting existing file (was Re: Query about P1003.2 'cp' utility)

Barry Margolin barmar at think.uucp
Sun Sep 9 04:01:18 AEST 1990


From: barmar at think.uucp (Barry Margolin)

In article <496 at usenix.ORG> cowan at 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 at think.com
{uunet,harvard}!think!barmar

Volume-Number: Volume 21, Number 94



More information about the Comp.std.unix mailing list