Mail Archives: djgpp-workers/1999/04/08/21:17:41
Bonjour
>
> DOS/Windows do this as well--mostly. The problem you bumped into is a
> very subtle case: the file in question was *created* by the program,
> and the program has written too few bytes to it. A file that's
> created anew does not have any disk space reserved for it by DOS,
> until such time as DOS flushes its buffers for the first time; only
> then it calls the block device driver (via the IOCTL functions of Int
> 21h) for the disk drive which allocates disk space for the file.
>
> Since the second open and read are issued *before* disk space is
> allocated for the file, the cache doesn't have any information about
> the disk clusters allocated for the file. And since the disk cache
> works on the block device (i.e. sector/cluster) level, and doesn't
> know anything about the names of the files which are cached, it really
> cannot associate the second open with the data from the first write.
>
> I think if you modify the program to write e.g. 16KB of data instead of
> just a few bytes, you will see that the test begins to work even without
> fsync.
>
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);
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. DJGPP doesn't maintain a consistent view of the file.
The explanation makes me wonder about a practice use by lots
of Unix programmers for temp files. A file is created and deleted
fd = create();
unlink(fd);
Even if the file is unlink .i.e not visible in the file system
namespace, you can still read/write to it. This is common practice.
Is it possible on DJGPP ?
--
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!
- Raw text -