Mail Archives: djgpp-workers/1999/04/08/21:25:58
> So this may also trigger the bug, if I don't fsync() ?
> char d, c = '1';
> a = open ("foo", O_CREAT|O_WRONLY, MODE);
> write(a, &c, 1);
> b = open ("foo", O_RDONLY);
> read (b, &d, 1);
Yes, that should fail also. In which case, we'd have to sync all
writes, not all fflushes, which would make performance horrible. It's
not DJGPP's fault. It's DOS's fault. The best we can do is work
around the bug when we can.
> IF yes, so putting fsync() in fflush() may correct the problem if I
> use the stdio API but doesn't fix the bug. This seems to be a
> peculiarity of DJGPP then a stdio implementation bug.
However, I'm trying to second-guess the programmer by putting it only
in fflush(). We can't easily fix the above program, but if the
programmer calls fflush() we can assume they're concerned about a
synchronization problem, and do our best to accomodate them.
> DJGPP doesn't maintain a consistent view of the file.
Like I said, it's not DJGPP it's DOS. Turbo-C should show the same
behavior (can someone verify this?) with your example.
> fd = create();
> unlink(fd);
If you do this in DOS, you'll corrupt your hard drive (again, it's
DOS's fault). There's a stdio.h function for creating temps that
automatically deletes the file *after* you close it. Use that
instead.
Note: unlink takes a file name, not a file handle.
- Raw text -