Opened 14 years ago

Closed 14 years ago

Last modified 11 years ago

#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


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)

dslo_1563.patch (612 bytes) - added by sayamindu 14 years ago.
Updated patch

Download all attachments as: .zip

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

Updated patch

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: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 11 years ago by dnarvaez

  • Component changed from sugar-datastore to Sugar
Note: See TracTickets for help on using tickets.