Date:	Mon, 19 Apr 1999 12:35:26 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Andris Pavenis <pavenis AT lanet DOT lv>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Update to dtou.c
In-Reply-To:	<B0000083789@stargate.astr.lu.lv>
Message-ID:	<Pine.SUN.3.91.990419123110.25741A-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 19 Apr 1999, Andris Pavenis wrote:

> 	Current version of of dtou and utod can replace file with corrupt one
> 	if there is some problem while writting output file (eg. disk is full).
> 	I tried to fix this problem and I think it should be fixed.

Yes, but fixing it means non-trivial (although not very complicated) 
changes to the sources.  Disk full is a very rare case, so I decided to 
not do this for v2.03, which is supposed to be a bugfix-only release, 
with minimal probability of introducing new bugs.

After v2.03, I think it is a good idea to make some clean-up, most
probably simply to adopt your version with a few minor changes.  (E.g.,
getftime and setftime don't support 3 time stamps on LFN platforms, which
is also not nice; utime solves this.)

> >   if (l>=0 && l2>=0 && err==0)
> >   {
> >     remove(fname);
> >     rename(tfname, fname);
> >     utime(fname, &tim1);
> >   }
> > 
> > I think just `rename' is enough, even in DJGPP.
> 
> I simply left that as it was and previous version had also remove().

That's because the original code was written for DJGPP v1.x, where rename 
didn't remove the target.

- Raw text -