List Ranges operation returns the list of valid ranges for a file.
List Ranges request may be constructed as follows. HTTPS is recommended.
|Method||Request URI||HTTP Version|
Replace the path components shown in the request URI with your own, as follows:
|myaccount||The name of your storage account.|
|myshare||The name of your file share.|
|mydirectorypath||Optional. The path to the parent directory.|
|myfile||The name of the file.|
For details on path naming restrictions, see Naming and Referencing Shares, Directories, Files, and Metadata.
The following additional parameters may be specified on the request URI.
||Optional. Version 2017-04-17 and newer. The sharesnapshot parameter is an opaque DateTime value that, when present, specifies the share snapshot to query for the file.|
The following table describes required and optional request headers.
||Required. Specifies the authorization scheme, account name, and signature. For more information, see Authorize requests to Azure Storage.|
||Required. Specifies the Coordinated Universal Time (UTC) for the request. For more information, see Authorize requests to Azure Storage.|
||Required for all authorized requests. Specifies the version of the operation to use for this request. For more information, see Versioning for the Azure Storage Services.|
||Optional. Specifies the range of bytes over which to list ranges, inclusively. If omitted, then all ranges for the file are returned.|
||Optional. Specifies the range of bytes over which to list ranges, inclusively.
If both the
The response includes an HTTP status code, a set of response headers, and a response body in XML format.
A successful operation returns status code 200 (OK).
For information about status codes, see Status and Error Codes.
The response for this operation includes the following headers. The response may also include additional standard HTTP headers. All standard headers conform to the HTTP/1.1 protocol specification.
||The date/time that the file was last modified. The date format follows RFC 1123. Any operation that modifies the file, including an update of the file’s metadata or properties, changes the file’s last modified time.|
||The ETag contains a value which represents the version of the file, in quotes.|
||The size of the file in bytes.|
||This header uniquely identifies the request that was made and can be used for troubleshooting the request. For more information, see Troubleshooting API Operations.|
||Indicates the version of the File service used to execute the request.|
||A UTC date/time value generated by the service that indicates the time at which the response was initiated.|
The response body includes a list of non-overlapping valid ranges, sorted by increasing address range. The format of the response body is as follows.
<?xml version="1.0" encoding="utf-8"?> <Ranges> <Range> <Start>Start Byte</Start> <End>End Byte</End> </Range> <Range> <Start>Start Byte</Start> <End>End Byte</End> </Range> </Ranges>
If the file’s entire set of ranges has been cleared, the response body will not include any ranges.
Only the account owner may call this operation.
The start and end byte offsets for each range are inclusive. Please refer to the Range Update Operations and Range Clear Operations examples for Put Range; these examples show what ranges are returned if you write or clear a 512-unaligned byte range from the file.
In a highly fragmented file with a large number of writes, a
List Ranges request can fail due to an internal server timeout. Applications retrieving ranges of a file with a large number of write operations should retrieve a subset of ranges at a time.