Tcl Source Code

There is a difference between the following two
scripts:
    #!/usr/local/bin/tclsh8.4
    foreach i { 0 1 2 3 4 5 6 7 8 9 } {
        puts [open "/tmp/test.out2" "a"] $i
    }
and
    #!/usr/local/bin/tclsh8.4
    foreach i { 0 1 2 3 4 5 6 7 8 9 } {
        puts [open "/tmp/test.out2" {WRONLY CREAT
APPEND}] $i
    }

In the first case, only a single value ("0") appears in
the file once the script has run, but in the second
case, all values written to the file appear in it. 
This difference in behaviour between the "a" mode and
the given set of options is highly surprising to me,
and a problem since many pieces of code that add
information to log files may well be using it assuming
that the latter behaviour will happen.  This could lead
to information loss when several processes append to
the same log file, which is very serious and fairly
tricky to reproduce reliably. Should the behaviour of
"a" (and possibly "a+"?) be altered so as to use the
APPEND flag internally, instead of a single seek when
the file is opened (which must be what happens at the
moment.)

Logged In: YES 
user_id=75003

The attached patches have been committed to HEAD and 8.4
branch head resp. They add O_APPEND to the list of flags
used when using 'a' to open a file, and provide an extended
testsuite for the new behaviour of 'a'.

File Added - 171163: 85.append.udiff

File Added - 171162: 84.append.udiff

Logged In: YES 
user_id=79902

The 8.4 branch isn't fixed either. My phrasing is meant to
indicate that neither is fixed, but perhaps it didn't come
out right.

I've not got a patch (and my sandboxes are full of things
that I don't want to check into the mainline).

Technically, there are compatability issues with going to
using O_APPEND. But nobody who is using it like stdio will
notice (stdio always used O_APPEND) except for the removal
of the bug! And anyone seeking on an append-only channel is
asking for trouble.

Logged In: YES 
user_id=75003

The id 1241593 is something in the FreeMind project. Which
entry is truly meant ?

Donal's phrasing (the emphasis on HEAD) seems to imply that
the 8.4 branch has been fixed. I cannot find a change however.

Do we have a patch for this somewhere ?

Would there be compatibility issues if we simply add
O_APPEND to the flags used by mode 'a' ? Like the channel
becoming unseekable ?

What happens if a non-appending channel is opened on a file
which has an 'a' channel open ?

Logged In: YES 
user_id=79902

The HEAD is still brain-damaged because it still doesn't use
O_APPEND for the 'a' mode (unlike what you'd expect if you
used stdio, like Tcl used to waaay back).

$ rm test1.out test2.out
$ tclsh8.5
% foreach i {1 2 3 4 5 6 7 8 9 0} {puts [open test1.out a]
$i};exit
$ tclsh8.5
% foreach i {1 2 3 4 5 6 7 8 9 0} {puts [open test2.out
{WRONLY CREAT APPEND}] $i};exit
$ wc -c test*
      2 test1.out
     20 test2.out
     22 total

Logged In: YES 
user_id=80530


What's the status of this one?

Is the resolution of 1241593
relevant?

Logged In: YES 
user_id=79902

The docs are correct as they stand.  Just very surprising to
someone coming from C, as fopen()'s mode args look very
similar but are not in this respect.  Perhaps a note that
"a" does not use O_APPEND internally would be a good idea,
though I still fear that people will get caught out.

If the original intention of "a" like modes was to mirror
what happens in stdio, the current behaviour is a bug no
matter how accurately we go about documenting it.  But I
don't actually know what classic Tcl (i.e. Tcl7.3 or 7.4
before cross-platform support was added) did here...

Logged In: YES 
user_id=72656

We should address this first as a doc issue.  If someone 
wants to write something up for 8.4.2, that's fine.  Otherwise 
this is a long-standing behavior, so not critical.

Logged In: YES 
user_id=79902

Tcl's behaviour is consistently poor across platforms.

Only setting the priority to 8 as there is a script-level 
workaround (use {WRONLY CREAT APPEND} instead of "a" 
as the flag to [open]).  It's still highly surprising that it is 
different from C (i.e. that Tcl can lose data where C would 
not) though this is just something that people writing code to 
add to log-files are going to have to beware of. :^/

At the very least, open.n ought to warn people a bit more 
clearly.  At least that'd be our CYA clause...

Logged In: YES 
user_id=72656

from the clt discussion, it's not even clear that the C behavior 
is reliable across platforms.  As long as Tcl is consistent, 
just document it, or leave it undefined.

Logged In: YES 
user_id=79902

The documentation as it stands is a correct rendering of
what actually happens.  It is just *very* surprising from
the point-of-view of anyone used to the way things happen in
C (i.e. both myself and Larry Virden found this
surprising.)  And such surprise is a bad thing for someone
expecting to simply translate a C idiom into Tcl and get
safe appending to a log-file.

IMO, features that can lead to surprising data loss are
dangerous bugs, no matter how well documented.  This is
particularly the case here, where the difference between the
"a" behaviour and the APPEND behaviour is not at all obvious
unless you know exactly what APPEND does and why it what it
does.

Logged In: YES 
user_id=72656

This does not appear to be anything more than a doc issue to 
me.