Re: unlink(2) or fopen(3) failing under cygwin

[Blair P. Houghton <blair at houghton dot net>]

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/