Skip to content

Get error when try to delete blob snapshot #84

Description

@jcookems

The message sent by using this code:

    service.createPageBlob(container, blob, 512);
    CreateBlobSnapshotResult snapshot = service.createBlobSnapshot(container, blob);
    options = new DeleteBlobOptions();
    options.setSnapshot(snapshot.getSnapshot());
    service.deleteBlob(container, blob, options);

is

DELETE http://XXX.blob.core.windows.net/XXX/XXX?snapshot=2012-05-21T16:15:40.1301586Z HTTP/1.1
x-ms-version: 2011-08-18
x-ms-delete-snapshots: include
...

which returns

HTTP/1.1 400 Value for one of the query parameters specified in the request URI is invalid.
QueryParameterName: snapshot
QueryParameterValue: 2012-05-21T16:15:40.1301586Z
Reason: This operation is only allowed on the root blob. Snapshot should not be provided.

The reason for this is explained (somewhat) in the documentation at http://msdn.microsoft.com/en-us/library/windowsazure/dd179413:

x-ms-delete-snapshots: {include, only}
...
This header should be specified only for a request against the base blob resource. If this header is specified on a request to delete an individual snapshot, the Blob service returns status code 400 (Bad Request).

There are a few potential fixes.

  1. Change the options class to make the DeleteSnaphotsOnly property nullable, and not include the header if null. But that makes the user have to do more work, because that makes them unable to delete a blob which has associated snapshots unless they explicitly set DeleteSnapshotsOnly to false. But that might be more appropriate for a service layer.
  2. Another choice would be to only add the x-ms-delete-snapshots header if there is no snapshot id provided, and silently ignore the user-supplied DeleteSnaphotsOnly property.
  3. Same as (2), but throw an exception to indicate the error (like invalid argument exception) to indicate that it is an error to specify both DeleteSnaphotsOnly and a snapshot.

I'm leaning toward (1), because that is most in line with what a service layer should do. A higher-level convenience layer can add in trickier logic for inferring the correct headers.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions