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

[Geo Carncross]

On Nov 29, 2007 3:03 AM, Richard M Kreuter <kreuter at progn.net> wrote:
> > 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).

The case that causes a problem is where another process *depends* on
the other file containing data before CLOSE. Most programs don't rely
on this probably because they'd be broken on NFS anyway, and probably
because it really isn't that useful.

When I said O_TRUNC is usually a bug, I mean that the programmer that
uses w+ *expects* the write to succeed and hasn't written any code to
deal with the situation where it doesn't. For example: Running YaBB (a
web-based bulletin board software) on a system with quotas is a good
way to wipe out your entire forum. Crashproof replacement would be
resistant to this.

As an aside from perl's documentation:

               ... thus '+<' is
               almost always preferred for read/write updates--the '+>' mode
               would clobber the file first.  You can't usually use either
               read-write mode for updating textfiles, since they have vari-
               able length records.  See the -i switch in perlrun for a better
               approach.

-i isn't crashproof (last I checked), but it could be in the future.

> 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.

I agree. That's much more common, but it's a scenario we can detect at
open time and fall back on the existing behavior (perhaps after
signaling 'sorry-not-crashproof or something- that way the user could
at least be warned)