Charles-François Natali <neolo...@free.fr> added the comment: > One could argue that something had happened before the fsync(2), > so that code which blindly did so is too dumb to do any right > decision anyway. Even PEP 3151 won't help.
I don't understand. If the syscall supposed to flush the disk's buffer cache fails - be it fcntl() or sync_file_range() - I think the error should be propagated, not silently ignored and replaced with another syscall which doesn't have the same semantic. That's all. > - I favour haypos fullsync() approach, because that could probably > make it into it. Yet Python doesn't offer any possibility to > access NetBSD DISKSYNC stuff sofar. Are you willing to update your patch accordingly? > - Currently the programmer must be aware of any platform specific > problems. I, for example, am not aware of Windows. How can > i give any guarantee to users which (will) use my S-Postman on > Windows? I need to put trust in turn into the Framework i am > using - Python. And that makes me feel pretty breathless. I agree. > - Fortunately Python is dynamic, so that one simply can replace > os.fsync(). Works once only though (think signal handlers :=). Yes, but since it's a fairly reasonable and useful feature, I think it could be merged. > + Aaarrg! I'm a liar!! I lie about - data integrity!!! Well, actually, some hard disks lie about this too :-) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11877> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
