#1563 closed defect (fixed)
call close() after completing version file write
Reported by: | sayamindu | Owned by: | alsroot |
---|---|---|---|
Priority: | Unspecified by Maintainer | Milestone: | Unspecified |
Component: | Sugar | Version: | Git as of bugdate |
Severity: | Unspecified | Keywords: | r! olpc-0.84 |
Cc: | dsd | Distribution/OS: | Unspecified |
Bug Status: | New |
Description
At OLPC, we are consistently seeing failures due to unclean shutdowns immediately after the datastore has been created. While I have tried to address some of the issues in #1562 I just noticed that close() is not being called for the version file in the datastore.
Attachments (1)
Change History (10)
comment:1 Changed 14 years ago by sayamindu
- Component changed from sugar to sugar-datastore
- Keywords r? added
- Version changed from Unspecified to Git as of bugdate
comment:2 Changed 14 years ago by sayamindu
- Summary changed from call close() after completing a file write to call close() after completing version file write
Changed 14 years ago by sayamindu
comment:3 Changed 14 years ago by sayamindu
- Owner changed from tomeu to alsroot
- Status changed from new to assigned
comment:4 Changed 14 years ago by dsd
- Cc dsd added
Python will automatically close the file when the reference count of the object drops to 0, which in this case will happen at the return point of the function.
The fsync changes may be worthwhile though, but they should be accompanied with a comment explaining why this particular file deserves the special treatment.
comment:5 Changed 14 years ago by erikos
- Bug Status changed from Unconfirmed to New
- Keywords r! added; r? removed
Don't we cope for the issue described here with setting the version to 0 if we can not read the file?
comment:6 Changed 14 years ago by erikos
comment:7 Changed 14 years ago by sascha_silbe
- Resolution set to fixed
- Status changed from assigned to closed
While we should check whether we recover well from crashes at random points during the migration, this ticket was about newly created data stores and thus should have been fixed by the commit mentioned above. Feel free to reopen if you can trigger a data store failure by corrupting any of the files it creates during first run.
comment:8 Changed 14 years ago by alsroot
- Keywords olpc-0.84 added
comment:9 Changed 10 years ago by dnarvaez
- Component changed from sugar-datastore to Sugar
Updated patch