On Jul 1, 2006, at 10:36 AM, David K. Hess wrote: > > It kind of looks like Durus is coded to be able to initialize zero- > length db files but I'm having trouble with it. This is useful as I > need to do some batch operations with Durus and the more secure > methods of managing temp files (tempfile.NamedTemporaryFile) > involve handing zero-length temp files to Durus. Durus is throwing > an exception in this case. Might this be a bug or is it just > something not supported by Durus? I'm using Durus 3.4.1. > If the file with the name given to the constructor already exists, it is opened in append mode. Because the file has no header with the magic string, it writes the header, saves a place for the index offset, and then writes the empty index. In _write_index(), we have these lines: fp.seek(len(self.MAGIC)) fp.write(p64(index_offset)) assert fp.tell() == len(self.MAGIC) + 8 You would think that seeking to a position and writing 8 bytes would leave the file pointer at that position plus 8. The assert statement here is just a sanity check, which in this case proved important. This is not an error that the caller could correct if only there were a nicer error message. The trap here is with the behavior of writes when a file is open in append mode. You can seek back for reads, but I think the fp is secretly advanced to the end when the index offset is written. I think I should change FileStorage so that it only uses append mode for nonempty files. --- If you give the don't provide any filename at all to the FileStorage constructor, it uses a NamedTemporaryFile. I guess there must be some reason that you wanted your own NamedTemproaryFile instead.