v1 API returns 200 OK when an admin deletes a deleted image

1. Delete an image in Glance

$ curl -v -H "X-Auth-Token:e546b5340e3041448beeee37323d5120" -H "Content-type: application/json" -X DELETE http://10.2.3.102:9292/v1/images/e05f88fb-9729-4f06-b6dd-90e600444212
* About to connect() to 10.2.3.102 port 9292 (#0)
* Trying 10.2.3.102... connected
> DELETE /v1/images/e05f88fb-9729-4f06-b6dd-90e600444212 HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: 10.2.3.102:9292
> Accept: */*
> X-Auth-Token:e546b5340e3041448beeee37323d5120
> Content-type: application/json
>
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=UTF-8
< Content-Length: 4
< X-Openstack-Request-Id: req-693d82be-0a35-41a8-a0d1-4d0c4fa67622
< Date: Wed, 03 Oct 2012 13:06:47 GMT
<
* Connection #0 to host 10.2.3.102 left intact
* Closing connection #0

Check image details:
--------------------------------
$ glance image-show e05f88fb-9729-4f06-b6dd-90e600444212
+------------------+--------------------------------------+
| Property | Value |
+------------------+--------------------------------------+
| container_format | ovf |
| created_at | 2012-10-03T13:05:12 |
| deleted | True |
| deleted_at | 2012-10-03T13:06:47 |
| disk_format | raw |
| id | e05f88fb-9729-4f06-b6dd-90e600444212 |
| is_public | False |
| min_disk | 0 |
| min_ram | 0 |
| name | demos_image |
| owner | b1519b1ea6b8439fb7d88b1ec79ceec2 |
| protected | False |
| size | 0 |
| status | deleted |
| updated_at | 2012-10-03T13:09:48 |
+------------------+--------------------------------------+

2. Retry Deleting the image(as Admin):
k$ curl -v -H "X-Auth-Token:e546b5340e3041448beeee37323d5120" -H "Content-type: application/json" -X DELETE http://10.2.3.102:9292/v1/images/e05f88fb-9729-4f06-b6dd-90e600444212
* About to connect() to 10.2.3.102 port 9292 (#0)
* Trying 10.2.3.102... connected
> DELETE /v1/images/e05f88fb-9729-4f06-b6dd-90e600444212 HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: 10.2.3.102:9292
> Accept: */*
> X-Auth-Token:e546b5340e3041448beeee37323d5120
> Content-type: application/json
>
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=UTF-8
< Content-Length: 4
< X-Openstack-Request-Id: req-30fd2d3e-97f8-484b-8d4f-11f682852875
< Date: Wed, 03 Oct 2012 13:09:48 GMT
<
* Connection #0 to host 10.2.3.102 left intact
* Closing connection #0

### This should have returned 404 NotFound or an appropriate error.

Check image details again:
--------------------------------------
$ glance image-show e05f88fb-9729-4f06-b6dd-90e600444212
+------------------+--------------------------------------+
| Property | Value |
+------------------+--------------------------------------+
| container_format | ovf |
| created_at | 2012-10-03T13:05:12 |
| deleted | True |
| deleted_at | 2012-10-03T13:09:48 |
| disk_format | raw |
| id | e05f88fb-9729-4f06-b6dd-90e600444212 |
| is_public | False |
| min_disk | 0 |
| min_ram | 0 |
| name | demos_image |
| owner | b1519b1ea6b8439fb7d88b1ec79ceec2 |
| protected | False |
| size | 0 |
| status | deleted |
| updated_at | 2012-10-03T13:09:48 |
+------------------+--------------------------------------+

Note that the "deleted_at" timestamp gets updated after the second delete attempt.
This works fine for an non-admin context, but the behavior should for this scenario should be fixed for an admin context too.