Russell Coker wrote:
> On Saturday 30 June 2007 19:52, Andy Green <andy@warmcat.com> wrote:
>> Russell Coker wrote:
>>> On Saturday 30 June 2007 00:35, Andy Green <andy@warmcat.com> wrote:
>>>> I don't think fsync() for individual files is really a fair answer,
>>> Why not?
>> $ man fsync
>> ...
>> DESCRIPTION
>>        fsync()  transfers  ("flushes")  all  modified  in-core data of
>> (i.e., modified buffer cache pages for) the file referred to by the file
>>        descriptor fd to the disk device (or other permanent storage
>> device) where that file resides.  The call blocks until the device  reports
>>        that the transfer has completed.  It also flushes  metadata
>> information associated with the file (see stat(2)).
>> ...
>>
>> You're proposing that doing an fsync() after every unpacked file is
>> righteous for all cases?  RPM will slow down dramatically for no real
>> benefit.  If power is lost partway through an archive unpack the package
>> is still in an inconsistent partial state on the drive despite that the
>> the atomic unit of inconsistency is supposedly now one file.  One way or
>> another you end up with half a kernel package or whatever.
> 
> It is not required that you call fsync() on each file separately.  You can 
> write data to a number of files (900 file descriptors is safe on all 
> platforms) and then loop through calling fsync() (or fdatasync()) on each 

Russell you care about having it way more than I care about not having
it, Jeff seems to agree it is worth having, so I guess we will have it.
 You can always find a bad time to hit reset and get a partial package
on your drive, but I certainly agree it is better if rpm exiting is a
trustworthy signal that it is after the delicate moment.  Why sync()
somehow doesn't deliver that and fsync() does... 99% of C code is not
"correct"... *shrug*.

-Andy