[two apps writing to file]Is this possible?

Wim Sturkenboom · 09-20-2007, 07:08 AM

Two applications writing data to a file (under windows).

I use teraterm pro (ttpro; terminal program) that writes received data to a file.
I have my own TCL application that writes timestamps to the same file by opening the file, writing the timestamp and closing the file.

Guess what, it does not do what it's supposed to do

I can see the timestamp when I open the file with an editor (pfe32) just after the timestamp is written. However new data from ttpro overwrites it. I assume that this is because ttpro does not close the file after a write and therefore the filepointer is still pointing to the last position.

Did I overlook something or is it simply not possible? If not possible and I'm correct with the assumption that ttpro does not close the file, is anybody aware of a terminal program including logging capabilities that does close the file after a write and works under Windows?

PS
hyperterm is even worse as it locks the file (a MS trademark?) so the other app gets a permission denied

matthewg42 · 09-20-2007, 09:07 AM

If you open the file in append mode, it will automatically write to the end of the file. You still might have to cope with problems where the writes happen at the same time though.

If you can't open the file in append mode, seek to the end before you write.

Wim Sturkenboom · 09-21-2007, 12:04 AM

My app does write (I can see it), but the second app (ttpro) does not seem to go to the end of the file before it writes, hence overwriting the timestamp.

I know that concurrent writing will give issues, but those issues are preferable over not having a timestamp at all.

Thanks for the thoughts.

paulsm4 · 09-21-2007, 12:16 AM

Hi -

Please consider:
a) opening (in append mode),
b) writing, and
c) closing the file
for each individual write.

Otherwise:
a) you'll need some kind of locking to synchronize writes between the two programs
b) you'll need to explicitly "flush" after each write
... and ...
c) you'll need to consider the unfortunate circumstance that even an explicit "flush" doesn't always write as promptly as you'd wish it to ("close", on the other hand, is much more reliable).

Just a thought .. pSM

Wim Sturkenboom · 09-21-2007, 02:54 AM

I did try a flush, but it did not help. I think that my side of the code is OK (tcl write procedure below), but I can not influence the other app (maybe if I can find the source code but in that case I can just as well write the whole app myself).

Code:

###########################################################
# write to a file
###########################################################
proc write_file {filename data} {

    # open output file
    # put filename between double quotes so it will handle spaces correctly
    if [catch "open \"$filename\" \"a\"" fpout] {
        # error opening
        puts "File error: $fpout"
        return 1
    }

    # prevent translation of '\n' to '\r\n'
#    fconfigure $fpout -translation binary

    puts $fpout $data
    close $fpout
    return 0
}

paulsm4 · 09-21-2007, 10:11 AM

Yup - you're already doing exactly what I was suggesting.

So I agree - your side of the code looks OK. It looks the other app is the culprit.

Good luck - and sorry I couldn't be of more help :-(

Your .. PSM

jim mcnamara · 09-21-2007, 04:01 PM

fdatasync() is guaranteed on POSIX-compliant boxes to write all data associated with the incore descriptor for the file (REALTIME), of which your process has one copy.

If it fails and sets errno to EINVAL, then your box does not support fully synchronized I/O.

Otherwise everybody;s data is guaranteed to be written to disk. Thre only weenie is if the other process is "manually" positioning its file pointer relative to the data it just wrote. Which is not very likely.

Try calling fdatasync(), then write your stuff, then fdatasync() again.