On 7/1/06, 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.
>

>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
> python2.4/site-packages/durus/file_storage.py", line 475, in
> _write_index
>      assert fp.tell() == len(self.MAGIC) + 8
> AssertionError

I came across this last week.  It's looking for a Durus identifier
("magic number") at the beginning of the file to verify it's a Durus
database.  Most file formats define this including images, word
processing files, and executables.  I suppose Durus could special-case
this, but the flip side is,'What if the user is expecting it to be an
existing database but somebody erased it?"  The user wants an
immediate exception in this case.  Otherwise he'll get an obsure
exception down the road when expected objects aren't found, and he'll
go hunting through his code to find out why they weren't created...
and barking up the wrong tree.

What Durus should do is consolidate all the "can't open database"
errors into a single meaningful exception.  I wanted to put a 'try'
around my database-opening code and found I had to catch both IOError
and AssertionError.  IOError makes sense if the file is missing  or
doesn't have read permission.  AssertionError is wrong because it's
the caller's error, not an inconsistency between one part of Durus and
another.  Plus, 'assert' is disabled if one compiles with
optimization.  I also got a weird "Bad file descriptor" error twice,
once with a device file (/dev/null)    and once I don't remember why.
The "durus" client catches the AssertionError and raises something
else.

I also wonder if FileStorage should have a 'create' argument.  That
way it knows the user's intention and can respond appropriately:

  - create=True: create the database if missing; overwrite if an empty
file.  Current behavior is to just open it if it exists.

  - create=False: exception if file is missing.

Alternatively, and 'overwrite' argument could have slightly different behavior:

   - overwrite=True: create the database unconditionally, truncating
any existing file and overwriting it.  Preserve existing permissions
of the file.

   - overwrite=False: exception if file is missing or not a Durus database.



--
Mike Orr