[Ecls-list] open :supersede and rename-file advise

[Richard M Kreuter]

"Geo Carncross" writes:
> On Nov 26, 2007 8:36 PM, Richard M Kreuter <kreuter at progn.net> wrote:
> >  IMO that the truly Right Thing is for implementors to
> > add a new :IF-EXISTS action, :TRUNCATE, which, if given, means to open
> > the existing file and truncate it, and to have :SUPERSEDE, :NEW-VERSION,
> > :RENAME, :RENAME-AND-DELETE all create a new file in some manner; I'd
> > prefer write-beside openings with rename-at-close-time behavior for all
> > those cases, too.  But I recognize that any implementation that changes
> > its implementation of the :IF-EXISTS actions will break compatibility
> > with itself, which is likely to frustrate its users, so someone ends up
> > losing in any case.)
> 
> Something I feel is important to note is that almost every use of
> O_TRUNC in unix applications is a bug; unix programs don't usually
> need truncate and its pervasiveness probably has more to do with the
> fact that the API is simpler.

Well, stdio's fopen(3) truncates the file under modes "w" and "w+", and
since several languages are implemented atop stdio, their default
open-for-writing modes are truncating (shell, awk, Perl, Python).  I
don't know of any language that does lazy superseding by default.
Additionally, as I describe in a separate message, sharing files among
processes, which is an ancient feature of Unix, may interact badly with
lazy superseding (at least there's little common practice about it).

Also, I have seen some environments that have depended on Unix file
system semantics in ways that wouldn't actually work with lazy
superseding as discussed: for example, a group of users who had write
access to files in some directories, but no write permission on the
directories.  These users were able to update the files, but not create
any new ones in those directories.  Such working environments are
obviously idiosyncratic, but nonetheless demand that the tools can do
truncating openings.  Since I don't think you want Lisp to be
constrained only to some uses, I think it's still very desirable to have
some truncating open mode.

> An application that relies on :SUPERSEDE actually meaning :TRUNCATE
> might exist. If it does, would it ever mean :RENAME-AND-DELETE to mean
> :TRUNCATE? Might this whole thing be avoided by using
> :RENAME-AND-DELETE instead?

In my way of considering things, no: on Unix, truncation preserves
inodes (and so, e.g., hard links, but also ownerships and permissions),
and doesn't depend on the permissions of the containing directory, while
while renaming changes inodes and depends on directory permissions. So
while only few applications really depend on truncation, those that do
will not, in fact, work under renaming.

--
RmK