sync'ing (was Re: (Fwd) Re: DOSFS bug fixes, IDE drivers and sample released)

[Chris Johns]

Ralf Corsepius wrote:
> Am Fre, 2003-05-23 um 03.50 schrieb Chris Johns:
>>
>>Should these calls also flush the user-space buffered (libc) data ?
> 
> 
> Good question, SUSv3 says:
> 
> fsync - synchronize changes to a file
> 
> int fsync(int fildes);
> 
> DESCRIPTION:
> 
>         The fsync() function shall request that all data for the open
>         file descriptor named by fildes is to be transferred to the
>         storage device associated with the file described by fildes in
>         an implementation-defined manner. The fsync() function shall not
>         return until the system has completed that action or until an
>         error is detected.
>         
> 
> I am not sure on how to interpret this, but I am inclined to read this
> as "fsync shall imply fflush".
> 

I agree. It is safer and this has got to be better.

> 
> Anyway, I think, the actual problem in Angelo's case is shutting down
> the "system too fast", before the fclose has completed (Assuming that
> "restartRtems" issues a shutdown/reboot or similar).
 >

Agreed. If you call reboot, or let a watchdog reset go off then data can be lost.

> If this presumption is true, waiting for a couple of seconds before
> exiting the process rsp. issueing a "reboot/reset" should help. 
> 
> If this doesn't help, probably something in RTEMS's fclose or the
> fs-code underneath is broken.
> 

I think fclose is ok, but I am concerned the FS API is not handling exit cleanly. I 
cannot see any of the FS sync interface hooked to exit. What if some code called 'exit' ?

Maybe sync is added and then called in _exit.

-- 
  Chris Johns, cjohns at cybertec . com . au