Summary: | Portage world files sometimes gets truncated | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Jo Are Rosland <joare> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | qbit |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 115839 |
Description
Jo Are Rosland
2005-12-01 04:28:33 UTC
writedict calls lack any form of error checking... I'm inclined to just have them throw an exception when failures occur. This immediately makes any failing code puke instead of silently swallowing it. Also deviates from the grab/write norms though. Thoughts? writedict() swallows the exception when it can't open the file for writing, but it has nothing after that. It would seem that there's no way to know that the write has failed... So... throw the exception, imo. We add in an optional swallow_exceptions=False, sed the existing code to set it to true ('cept where we need to have it puke), then gradually ween the code away from swallow_exceptions=True Thoughts? My point is that the only time an exception is raised is when it fails to open the file. If the open fails, no data will be lost. What seems to be happening is that the file is opened successfully (and truncated), data is written into the buffer and then the file is closed yet the close fails without any exception being raised. write to a tmp file, mv it into place via a rename... nice way to handle atomicity issues also. fixed in svn. *** Bug 128362 has been marked as a duplicate of this bug. *** |