Message169558
| Author |
loewis |
| Recipients |
eric.snow, loewis, ned.deily, petri.lehtinen, python-dev, sbt, trent |
| Date |
2012年08月31日.16:45:42 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<5040EA35.7020607@v.loewis.de> |
| In-reply-to |
<1346429884.22.0.787903927296.issue15819@psf.upfronthosting.co.za> |
| Content |
Am 31.08.12 18:18, schrieb Eric Snow:
> Doesn't EIO cover pathologies which we don't want to silence? I could see adding EROFS though.
[This should *really* be its own issue]
Sure, EIO indicates normally something pathological, such as a broken
cable to the disk. I'm not sure it needs to be reported, though, at
least not when coming out of open(): we are trying to write to the
cache, and that failed really bad. However, this is not bad for Python:
if we don't have a cache file, we can still continue executing.
If we get EIO in the middle of writing, this would be worse.
So as a work-around, I could propose to map OSError(EIO) coming
out of open into PermissionError(EIO) (inside _bootstrap).
But as I said: I'd also be fine with declaring this VM software
unsupported. If this work-around is added, we should record the
exact software for which it is a work-around, so we can remove
it in the future. |
|