您现在访问的是微软AZURE全球版技术文档网站，若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站，请访问 https://docs.azure.cn.
Create Share operation creates a new share under the specified account. If the share with the same name already exists, the operation fails.
The share resource includes metadata and properties for that share. It does not include a list of the files contained by the share.
Create Share 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. Note that it may include only lower-case characters.|
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. The timeout parameter is expressed in seconds. For more information, see Setting Timeouts for File Service Operations.|
The following table describes required and optional request headers.
||Required. Specifies the authentication scheme, account name, and signature. For more information, see Authentication for the Azure Storage Services.|
||Required. Specifies the Coordinated Universal Time (UTC) time for the request. For more information, see Authentication for the Azure Storage Services.|
||Required for all authenticated requests. Specifies the version of the operation to use for this request. For more information, see Versioning for the Azure Storage Services.|
||Optional. A name-value pair to associate with the share as metadata.
Metadata names must adhere to the naming rules for C# identifiers.
||Optional. Supported in version 2015-02-21 and above. Specifies the maximum size of the share, in gigabytes. Must be greater than 0, and less than or equal to 5TB (5120).|
PUT https://myaccount.file.core.windows.net/myshare?restype=share HTTP/1.1 Request Headers: x-ms-version: 2015-02-21 x-ms-date: <date> x-ms-meta-Name: StorageSample Authorization: SharedKey myaccount:Z5043vY9MesKNh0PNtksNc9nbXSSqGHueE00JdjidOQ=
The response includes an HTTP status code and a set of response headers.
A successful operation returns status code 201 (Created).
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 ETag contains a value which represents the version of the share, in quotes.|
||Returns the date and time the share was last modified. The date format follows RFC 1123. For more information, see Representation of Date-Time Values in Headers.
Any operation that modifies the share or its properties or metadata updates the last modified time. Operations on files do not affect the last modified time of the share.
||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.|
Response Status: HTTP/1.1 201 Created Response Headers: Transfer-Encoding: chunked Date: <date> ETag: "0x8CB14C3E29B7E82" Last-Modified: <date> x-ms-version: 2015-02-21 Server: Windows-Azure-File/1.0 Microsoft-HTTPAPI/2.0
Only the account owner may call this operation.
Shares are created immediately beneath the storage account. It's not possible to nest one share beneath another.
You can specify metadata for a share at the time it is created by including one or more metadata headers on the request. The format for the metadata header is
If a share by the same name is being deleted when
Create Share is called, the server will return status code 409 (Conflict), with additional error information indicating that the share is being deleted.
The share size quota can be used to limit the size of files stored on the share. It does not limit the size of snapshots. The overhead associated with files that is used in computing the billing size for the storage account is not accounted for in the quota.
When the sum of the sizes of the files on the share exceeds the quota set on the share, attempts to increase the size of a file will fail, and creating new non-empty files (via REST) will fail. You will still be able to create empty files.
Changing or setting the quota has no effect on billing. You will still be billed for the size of the files plus the overhead.