Message140920
| Author |
neologix |
| Recipients |
nadeem.vawda, neologix, pitrou, ronaldoussoren, santoso.wijaya, sdaoden, vstinner |
| Date |
2011年07月22日.22:26:02 |
| SpamBayes Score |
4.684697e-12 |
| Marked as misclassified |
No |
| Message-id |
<CAH_1eM24Y0ADauNB2EJXYw32_g_QpBnC-q-CS7S5oUfY2oym5w@mail.gmail.com> |
| In-reply-to |
<20110719122224.GA40111@sherwood.local> |
| Content |
> 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 :-) |
|