Hannu E K Nevalainen <garbage_collector <at> telia.com> writes: > > Does anyone know of any reason an fopen on the > > just-unlinked file would fail under Cygwin? > > IIRC this has been up earlier; unlink() isn't atomic.
Hence the loop. I'm sure I've even had to do this to this exact file before (but I'm putting the code onto a new machine and managed not to have the code from the old machine anywhere I could get at it...it's kind of a long story...) It turns out the real problem is that trn is doing this protocol for killfile processing: on entering newsgroup: fp1 = open killfile read fp1, apply data to newsgroup on exiting newsgroup: unlink killfile fp2 = open killfile (***) write new data to fp2 close fp2 close fp1 fp1 = open killfile Cygwin on Win XP (at least) doesn't like the (***) line. I don't like it either. It's just wrong to be able to open an unclosed file just because you unlinked it. It must work on BSD and/or SysV though, or trn would never have gone anywhere. I fixed it by changing the rewrite code to use a temp file for the output, then close the old file and rename the temp file on top of it: on exiting newsgroup: fp2 = open tempfile write new data to fp2 close fp2 close fp1 move tempfile to killfile (using rename) fp1 = open killfile It works perfectly now, and doesn't look quite so shroom-induced. It doesn't even use unlink(2) unless certain rule changes cause the killfile to end up empty on rewrite. Thanks for the pointers. --Blair "pointers. heh. get it?" -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
