From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 12 Oct 2015 13:37:22 +0200 From: Steffen Nurpmeso To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20151012113722.LaRyrA_0L%sdaoden@yandex.com> References: <385c85ca703ac8d441c4227d1bb24643@u2.inri> <8675dd67db7f50f93257f1df50e73767@lilly.quanstro.net> In-Reply-To: <8675dd67db7f50f93257f1df50e73767@lilly.quanstro.net> User-Agent: s-nail v14.8.5-106-gf8740e1 Subject: Re: [9fans] off topic - a good Git reference Topicbox-Message-UUID: 7283d00c-ead9-11e9-9d60-3106f5b1d025 erik quanstrom wrote: |On Wed Oct 7 14:25:58 PDT 2015, elbingmiss@gmail.com wrote: |in the case of system crash, fsync doesn't provide strong \ |guarantees that the |write will not be lost, or the fs not corrupted even in li\ |nux. some versions of |the linux kernel do nothing on fsync, fsync doesn't actual\ Linux fsync(2) says that the file itself is fine after it, but for the filesystem metadata you need an additional fsync(2) on the directory the file resides in. The final wording of the related POSIX issue[1] states that the latter is only necessary if directory entries have been created or removed (also regarding rename(2) which needs two fsync(2) calls; luckily we're binary only), and noone has opposed to this wording in more than two years. (Mac OS X Snow Leopard had a F_FULLFSYNC fcntl(2) which provided the fully-synced guarantee, as in _os_fsync = os.fsync def __fullfsync(fd): if not SAFE_FSYNC: return _os_fsync(fd) try: fcntl.fcntl(fd, fcntl.F_FULLFSYNC) except IOError as e: if e.errno == errno.ENOTTY: return _os_fsync(fd) raise os.fsync = __fullfsync which i thought of as a good idea, from a programmers point of view who wants to get it done.) [1] http://austingroupbugs.net/view.php?id=672#c1618 --steffen