durusmail: durus-users: Initializing zero length .durus files?
Initializing zero length .durus files?
2006-07-01
2006-07-01
2006-07-03
Initializing zero length .durus files?
David Binger
2006-07-03
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.

reply