[MacPorts] #16145: Erlang R12B-3 needs a patch for fsync problem

[MacPorts]

#16145: Erlang R12B-3 needs a patch for fsync problem
-------------------------------------+--------------------------------------
  Reporter:  jerry.jalava at gmail.com  |       Owner:  bfulgham at macports.org
      Type:  defect                  |      Status:  new                  
  Priority:  Normal                  |   Milestone:                       
 Component:  ports                   |     Version:  1.6.0                
Resolution:                          |    Keywords:                       
-------------------------------------+--------------------------------------
Comment (by febeling at macports.org):

 It is a bit hard to tell because the errors you get are potentially
 dependent load and io patters of the OS kernel.

 I had problems in fairly simple test cases though, and those are indeed
 gone now.  Just for the record, the whole
 problem is not something esoteric which only couchdb encounters, but it is
 simply the behavior of the function
 file:sync/1 from kernel. OTOH, one can't really speak of an erlang bug,
 because the documented behavior explicitly
 makes no guarantee:
 {{{
 sync(IoDevice) -> ok | {error, Reason}
 Types:

 IoDevice = io_device()
 Reason = ext_posix() | terminated
 Makes sure that any buffers kept by the operating system (not by the
 Erlang runtime system) are written to disk. On some platforms, this
 function might have no effect.
 }}}

 But I don't see how you could program any serious disk persistence without
 this function. This is also the view held in the
 fsync man page from Apple.

 After the patch I used dtruss to watch syscalls while syncing a file from
 an erlang shell
 and this confirms, that we call fctnl now
 {{{
 79500/0x7f944f0:  fcntl(0x7, 0x33, 0xFFFFFFFFB01A8BD8)           = 0 0
 }}}
 0x33 or 51 is the value of F_FULLSYNC
 {{{
 ./sys/fcntl.h:206:#define F_FULLFSYNC     51            /* fsync + ask the
 drive to flush to the media */
 }}}

 And that was the intention of the patch. So I think this issue could be
 closed.

-- 
Ticket URL: <http://trac.macports.org/ticket/16145#comment:6>
MacPorts <http://www.macports.org/>
Ports system for Mac OS