On Mon, 22 Nov 1999, Brian Fundakowski Feldman wrote:

> On Mon, 22 Nov 1999, Zhihui Zhang wrote:
> 
> > 
> > Please take a look at the following piece of code that creates a large
> > hole in a file named hole.dat.  It tries to write 0x30-0x39 both at the
> > front and the tail of that file, the hole is therefore in the middle.
> > 
> > main()
> > {
> >     char c;
> >     FILE * fp;
> > 
> >     fp = fopen("hole.dat", "w");
> > 
> >     for (c=0x30; c<0x3a; c++) fputc(c, fp);
> >     fputc('\n',fp);
> >     fflush(fp);                             /* XXX */
> >     lseek(fileno(fp),  3 * 8192, SEEK_CUR);
> 
> This should be fseek() and not lseek().
> 
> >     for (c=0x30; c<0x3a; c++) fputc(c, fp);
> >     fputc('\n',fp);
> >     fclose(fp);
> > }
> > 
> > If I remove the fflush(fp), then the characters 0x30-0x39 will be all
> > written at the end of the file (use hexdump to find out), not as expected
> > (one at the beginning and the other at the end).  It seems to me that the
> > first for loop happens AFTER the lseek() statement without fflush().  Can
> > anyone explain this to me?  I am using FreeBSD 3.3-Release.
> 
> That's because you're not using fseek() like your should be using
> for FILE * IO.  Don't mix FILE *fp and int fd operations callously.

Brian is right, a long while back it took me _forever_ to figure
out that the reason I was having a ton of trouble (nulls appearing
in a file) was that one part of the program was using stdio and
creating the file, then it would hand it off to another part which
used direct io, however I wasn't fflush()'ing or fclose()'ing the
FILE before handing it off.  Did I mention that the problem was
difficult to reproduce because the dataset would change thereby 
masking the problem more often than not?

*doh*

yah, don't mix stdio and direct io. :)

-Alfred



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to