Date: Tue, 20 Jul 1999 11:53:34 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Alain Magloire <alainm AT rcsm DOT ece DOT mcgill DOT ca>
cc: djgpp-workers AT delorie DOT com
Subject: Re: ftruncate
In-Reply-To: <199907191944.PAA14676@mccoy2.ECE.McGill.CA>
Message-ID: <Pine.SUN.3.91.990720114223.4115C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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
Precedence: bulk


On Mon, 19 Jul 1999, Alain Magloire wrote:

> > Our implementation does.  I am not sure  whether this is a bug in the
> > GNU application or in our implementation.  One Unix box says in
> 
> That's a bug in the implementation.

Thanks, I corrected this.

> An lseek()/write() will not do it, sometimes you want to create
> a "hole" in the file by lseek()ing pass the size not ftruncate()ed
> i.e. readjust its size.

I think on DOS lseek followed by write does produce a hole like that.
On DOS, a write of zero bytes has the effect of adjusting the file's
size to the current byte position.