Copier un fichier

L’opération Copy File copie un objet blob ou un fichier dans un fichier de destination dans le compte de stockage. Cette opération est prise en charge dans la version 2015-02-21 et ultérieure pour les partages de fichiers avec le protocole SMB activé et prise en charge dans la version 2025-05-05 et versions ultérieures pour les partages de fichiers avec le protocole NFS activé.

Disponibilité du protocole

Protocole de partage de fichiers activé	Disponible
SMB
NFS

Demander

La requête Copy File est construite comme suit. Nous vous recommandons d’utiliser HTTPS.

À compter de la version 2013-08-15, vous pouvez spécifier une signature d’accès partagé pour le fichier de destination s’il se trouve dans le même compte que le fichier source. À compter de la version 2015-04-05, vous pouvez également spécifier une signature d’accès partagé pour le fichier de destination s’il se trouve dans un autre compte de stockage.

Remplacez les composants de chemin d’accès indiqués dans l’URI de requête par vos propres composants, comme suit :

Pour plus d’informations sur les restrictions de nommage de chemin d’accès, consultez nommage et référencement de partages, répertoires, fichiers et métadonnées.

Paramètres d’URI

Vous pouvez spécifier les paramètres supplémentaires suivants sur l’URI de requête :

En-têtes de requête

Les en-têtes de requête obligatoires et facultatifs sont décrits dans les tableaux suivants :

En-têtes de requête courants

En-têtes de requête SMB uniquement

En-têtes de requête NFS uniquement

Corps de la demande

Aucun.

Réponse

La réponse inclut un code d’état HTTP et un ensemble d’en-têtes de réponse.

Code d’état

Une opération réussie retourne le code d’état 202 (accepté). Pour plus d’informations sur les codes d’état, consultez Les codes d’état et d’erreur.

En-têtes de réponse

La réponse de cette opération inclut les en-têtes dans les tableaux suivants. La réponse peut également inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification de protocole HTTP/1.1 .

En-têtes de réponse courants

En-têtes de réponse SMB uniquement

Aucun.

En-têtes de réponse NFS uniquement

Aucun.

Corps de la réponse

Aucun

Exemple de réponse

Response Status:  
HTTP/1.1 202 Accepted  
  
Response Headers:   
Last-Modified: <date>   
ETag: "0x8CEB669D794AFE2"  
Server: Windows-Azure-File/1.0 Microsoft-HTTPAPI/2.0  
x-ms-request-id: cc6b209a-b593-4be1-a38a-dde7c106f402  
x-ms-version: 2015-02-21  
x-ms-copy-id: 1f812371-a41d-49e6-b123-f4b542e851c5  
x-ms-copy-status: pending  
Date: <date>  

Autorisation

Cette opération peut être appelée par le propriétaire du compte ou par un client disposant d’une signature d’accès partagé qui a l’autorisation d’écrire dans le fichier de destination ou son partage. Notez que la signature d’accès partagé spécifiée sur la demande s’applique uniquement au fichier de destination.

L’accès au fichier source ou à l’objet blob est autorisé séparément, comme décrit dans les détails de l’en-tête de requête x-ms-copy-source.

Le tableau suivant décrit comment les objets de destination et source d’une opération de Copy File peuvent être autorisés :

Attributs du système de fichiers

Autorisations de fichier POSIX (mode)

Les autorisations de fichier POSIX peuvent être spécifiées numériquement dans un format octal numérique 12 bits ou dans un format symbolique « rwx ». Exemples:

• « 0644 » ou « rw-r--r--- » : l’utilisateur (propriétaire du fichier) dispose d’une autorisation de lecture et d’écriture. Le groupe dispose d’une autorisation de lecture. D’autres disposent d’une autorisation de lecture.
• « 0755 » ou « rwxr-xr-x » : l’utilisateur (propriétaire du fichier) dispose d’une autorisation de lecture, d’écriture et d’exécution. Le groupe dispose d’une autorisation de lecture et d’exécution. D’autres disposent d’autorisations de lecture et d’exécution.

Format octal numérique

Les trois numéros octal d’ordre le plus bas représentent les autorisations pour le propriétaire/l’utilisateur, le groupe et d’autres et sont indiqués à l’aide d’un nombre octal (0-7), formé à l’aide d’une combinaison au niveau du bit « 4 » (Lecture), « 2 » (Écriture), « 1 » (Exécuter). Le numéro octal de l’ordre le plus élevé (0-7) est utilisé pour indiquer une combinaison d’autorisations « 4 » (SetUID), « 2 » (SetGID), « 1 » (StickyBit).

Format symbolique « rwx »

Les autorisations de propriétaire/utilisateur, de groupe et d’autres sont indiquées à l’aide d’une combinaison de caractères « r » (lecture), « w » (écriture) et « x » (Exécuter).

Remarques

L’opération de Copy File peut se terminer de façon asynchrone. Vous pouvez utiliser l’ID de copie que l’en-tête de réponse x-ms-copy-id retourne pour vérifier l’état de l’opération de copie ou pour l’annuler. Azure Files copie les fichiers de manière optimale.

Si le fichier de destination existe, il est remplacé. Vous ne pouvez pas modifier le fichier de destination pendant que l’opération de copie est en cours.

L’opération Copy File copie toujours l’intégralité de l’objet blob ou du fichier source. La copie d’une plage d’octets ou de blocs n’est pas prise en charge.

La source d’une opération de Copy File peut être un fichier qui réside dans un instantané de partage. La destination d’une opération de Copy File ne peut pas être un fichier qui réside dans un instantané de partage.

Lorsque la source d’une opération de copie fournit des valeurs ETag, s’il existe des modifications apportées à la source pendant que l’opération est en cours, elle échoue. Une tentative de modification du fichier de destination pendant qu’une opération de copie échoue avec le code d’état 409 (conflit).

La valeur ETag du fichier de destination change lorsque l’opération de Copy File démarre. Il continue de changer fréquemment pendant l’opération de copie.

Copie des propriétés et des métadonnées

Lorsqu’un objet blob ou un fichier est copié, les propriétés système suivantes sont copiées dans le fichier de destination avec les mêmes valeurs :

• Content-Type
• Content-Encoding
• Content-Language
• Content-Length
• Cache-Control
• Content-MD5
• Content-Disposition

Le fichier de destination est toujours de la même taille que l’objet blob source ou le fichier. La valeur de l’en-tête Content-Length pour le fichier de destination correspond à la valeur de cet en-tête pour l’objet blob ou le fichier source.

Copie d’un objet blob ou d’un fichier loué dans un fichier

L’opération Copy File lit uniquement à partir de l’objet blob ou du fichier source. Par conséquent, un bail sur l’objet source n’affecte pas l’opération. L’opération Copy File enregistre la valeur ETag de l’objet blob ou du fichier source au démarrage de l’opération. Si la valeur ETag change avant la fin de l’opération de copie, l’opération échoue. Vous pouvez empêcher les modifications apportées à l’objet blob source du fichier en la louant pendant l’opération de copie.

Si le fichier de destination a un bail infini actif, vous devez spécifier son ID de bail dans l’appel à l’opération de Copy File. Pendant que l’opération de copie est en attente, toute opération de bail sur le fichier de destination échoue avec le code d’état 409 (conflit). Un bail infini sur le fichier de destination est verrouillé de cette façon pendant l’opération de copie, que vous copiez dans un fichier de destination qui a un nom différent de la source ou copie dans un fichier de destination qui porte le même nom que la source. Si le client spécifie un ID de bail sur un fichier qui n’existe pas encore, Azure Files retourne le code d’état 412 (Échec de la condition préalable).

Utilisation d’une opération de copie en attente

L’opération Copy File peut terminer la copie asynchrone des fichiers. Utilisez le tableau suivant pour déterminer l’étape suivante en fonction du code d’état qui Copy File retourne :

Pendant et après une opération de Copy File, les propriétés du fichier de destination contiennent l’ID de copie de l’opération de Copy File et l’URL de l’objet blob ou du fichier source. Une fois l’opération terminée, Azure Files écrit la valeur de temps et de résultat (success, failedou aborted) dans les propriétés du fichier de destination. Si l’opération a un résultat failed, l’en-tête x-ms-copy-status-description contient une chaîne de détails d’erreur.

Une opération de Copy File en attente a un délai d’attente de deux semaines. Une tentative de copie qui n’a pas terminé après deux semaines expire et laisse un fichier vide avec le champ x-ms-copy-status défini sur failed et le champ x-ms-status-description défini sur 500 (OperationCancelled). Les erreurs intermittentes et non irrécupérables qui peuvent se produire pendant une opération de copie peuvent entraver la progression de l’opération, mais elles ne provoquent pas l’échec. Dans ce cas, x-ms-copy-status-description décrit les erreurs intermittentes.

Toute tentative de modification du fichier de destination pendant l’opération de copie échoue avec le code d’état 409 (conflit), « Copier le fichier en cours ».

Si vous appelez une opération de Abort Copy File, un en-tête x-ms-copy-status:aborted s’affiche. Le fichier de destination aura des métadonnées intactes et une longueur de fichier de 0 octets. Vous pouvez répéter l’appel d’origine pour Copy File pour réessayer l’opération.

Facturation

Le compte de destination d’une opération de Copy File est facturé pour qu’une transaction démarre l’opération. Le compte de destination entraîne également une transaction pour chaque demande d’annulation ou demande l’état de l’opération de copie.

Lorsque le fichier source ou l’objet blob se trouve dans un autre compte, le compte source entraîne des coûts de transaction. En outre, si les comptes source et de destination résident dans différentes régions (par exemple, USA Nord et USA Sud), la bande passante que vous utilisez pour transférer la demande est facturée au compte source comme sortie. La sortie entre les comptes au sein de la même région est gratuite.

Voir aussi

• opérations sur les fichiers
• Autoriser les demandes adressées au stockage Azure
• l’état et les codes d’erreur
• codes d’erreur Azure Files
• abandonner le copier le fichier