So, it seems, there's no way to sidestep the buffer "parking" of the data while writing on disk .....
I made some test this morning and I realized that my problem could be in the opening of the file, not in the writing . I use : _open (file , _O_CREAT | _O_BINARY | _O_RDWR, _S_IREAD | _S_IWRITE)) to open my remote file, and it always succeeds : so I made the test by just opening and closing the file , expecting an empty file to be created . Instead, no file was created at all. --- In [email protected], "Nico Heinze" <[EMAIL PROTECTED]> wrote: > > --- In [email protected], "spudgun0" <spudgun0@> wrote: > > > > Hi Mark and thank you for answering . > > I tried the commit() as a first way out but it > > didn't work. More, when I stop the program, and > > I gracefully shutdown all the threads, so that > > I expect all the I/O buffers to be flushed on > > the disk, it doesn't work either. > > I even tried to change the remote folder (where > > the thread writes) with a local one , but it had > > no effect. Some told me that the difference > > between using _open() (or _sopen() ) and fopen() > > is that in the first one the data is immediately > > flushed (i.e. the file system doesn't use its > > buffer) , the other instead, the fopen(), uses > > OS buffers so the real flushing of the data can be > > delayed .... but it seems this is not totally true > <snip> > > You're right, this is NOT true. open() and fopen() do use OS buffers > under every sort of Unix/Linux; the sole exception is if you open() or > fopen() a raw device, but that's really a different story. > > There have been OS's which didn't buffer in all cases; the earliest > versions of MS-DOS for example didn't buffer if you didn't explicitly > reserved RAM for this purpose, and also TOS (Atari ST) didn't > automatically buffer file I/O in the earliest versions. But nowadays > you can almost always bet on every halfway modern OS using buffers, > whether you like that or not. > > Just my 2 pennies. > > Regards, > Nico >
