> Theo de Raadt wrote:
> > How does sync() fix this? Please explain this. Look at the source
> > code.
> > sync() is an asyncronous call requesting syncronization, and once
> > it has marked the blocks that should be pushed, it returns before
> > the work has been done.
> Ah, indeed.
> > > 2. cp could do an fsync call. There was a thread about this a while ago?
> > How does fsync fix this? What if it returns an error. What do you do next.
> > Should cp spin until fsync returns non-error, or what should it do.
> Exit with an error? Same as if it got EIO or ENOSPC from a write? Then the
> command chain will stop before the mv.
The OP demonstrated a problem. Any solution presented should try to fix
the problem, not just "maybe".
> Even after many tries, I have not yet been able to corrupt the
> filesystem so fsck cannot repair it without manual intervention.
Another less severe corner fail case I have found is that on a couple of buggy
386 laptops (that will be replaced soon anyway) with temperamental over temp
shutdowns on some bootups (and now failing host controller, I'm guessing due to
age/damage). I have found LOST+FOUND can fill up the filesystem, preventing
library and kernel randomisation from taking affect. I have a script to check
and remove older LOST+FOUND files. It's unlikely that there would be anything
important lost on these browsing machines anyway.