La commande Linux `mv` : Référence technique complète et guide d’utilisation avancée

La commande mv sous Linux déplace ou renomme des fichiers et des répertoires en mettant à jour les métadonnées du système de fichiers — plus précisément l’entrée de répertoire — sans copier les données lorsqu’elle opère au sein du même système de fichiers. Cela en fait une opération atomique et quasi-instantanée pour les déplacements sur la même partition, quelle que soit la taille du fichier.

Comprendre cette distinction sépare les utilisateurs occasionnels des administrateurs capables de diagnostiquer pourquoi un déplacement entre deux points de montage se comporte différemment d’un déplacement au sein d’une seule partition, pourquoi certaines opérations mv déclenchent des E/S disque tandis que d’autres non, et comment utiliser la commande en toute sécurité dans des environnements de production où l’intégrité des données est non négociable.

Ce que la commande mv fait réellement en coulisses

Lorsque vous exécutez mv source destination sur le même système de fichiers, le noyau appelle rename(2) — un appel système unique qui réassigne atomiquement l’entrée de répertoire. Aucune donnée n’est lue ou écrite sur le disque. Le numéro d’inode reste identique ; seul le chemin change.

Lorsque la source et la destination résident sur des systèmes de fichiers différents (partitions différentes, montages NFS ou bind mounts), mv revient à une séquence copier-puis-supprimer : il lit les données source, les écrit vers la destination, et dissocie la source uniquement après une écriture réussie. Cela a des implications critiques :

• Les déplacements inter-systèmes de fichiers interrompus peuvent laisser une copie partielle à la destination et l’original intact à la source, ou — dans les pires scénarios — supprimer la source avant que l’écriture ne soit terminée.
• Les déplacements de fichiers volumineux entre systèmes de fichiers consomment de la bande passante d’E/S et du temps proportionnels à la taille du fichier.
• Les permissions et la propriété peuvent ne pas être transférées correctement si le système de fichiers de destination ne prend pas en charge le même modèle de permissions (par exemple, FAT32, certains partages réseau).

Cette différence de comportement est invisible dans la syntaxe de la commande, mais fondamentale pour les décisions d’administration système sur les serveurs exécutant un Hébergement VPS ou des Serveurs Dédiés avec plusieurs points de montage.

Syntaxe et options principales

mv [OPTIONS] SOURCE DESTINATION
mv [OPTIONS] SOURCE... DIRECTORY

Arguments :

SOURCE — Un ou plusieurs fichiers ou répertoires à déplacer ou renommer.
DESTINATION — Le chemin cible. S’il s’agit d’un répertoire existant, la source est placée à l’intérieur. S’il s’agit d’un chemin inexistant, la source est renommée avec ce chemin.

Référence complète des options

Option
Forme longue
Comportement


-i
--interactive
Demande confirmation avant d’écraser un fichier existant


-f
--force
Supprime toutes les invites ; écrase sans confirmation


-n
--no-clobber
N’écrase jamais un fichier existant ; ignore silencieusement


-u
--update
Déplace uniquement si la source est plus récente que la destination ou si la destination est absente


-v
--verbose
Affiche chaque nom de fichier au fur et à mesure de son traitement


-b
--backup
Crée une sauvegarde de chaque fichier qui serait écrasé


--suffix=SUFFIX
--suffix
Définit le suffixe de sauvegarde (par défaut ~)


--strip-trailing-slashes
—
Supprime les barres obliques finales des arguments source


-t DIR
--target-directory
Déplace toutes les sources dans le répertoire spécifié


-T
--no-target-directory
Traite la destination comme un fichier normal, et non comme un répertoire


Remarque : L’option -r / -R mentionnée dans de nombreux tutoriels n’existe pas dans GNU mv. Contrairement à cp, la commande mv déplace les répertoires de manière récursive par défaut car elle opère sur les entrées de répertoire, et non sur le contenu des fichiers. Passer -r à mv sur la plupart des distributions Linux produira une erreur ou sera ignoré silencieusement selon l’implémentation.
Opérations de base avec des exemples précis
Déplacer un fichier vers un autre répertoire
mv /home/user/report.txt /var/backups/
Le fichier report.txt est déplacé vers /var/backups/. Si /var/backups/ se trouve sur le même système de fichiers que /home/user/, l’opération est instantanée. Sinon, les données sont physiquement copiées.
Renommer un fichier sur place
mv old_config.conf new_config.conf
Les deux chemins partagent le même répertoire parent, il s’agit donc d’un appel rename(2) pur — aucun déplacement de données, aucune E/S.
Déplacer plusieurs fichiers dans un répertoire
mv file1.txt file2.txt file3.txt /var/www/html/assets/
Lorsque plusieurs sources sont spécifiées, la destination doit être un répertoire existant. Si elle n’existe pas, mv retournera une erreur.
Déplacer un répertoire
mv /home/user/project /opt/projects/
L’arborescence complète du répertoire — y compris tous les fichiers imbriqués et sous-répertoires — est déplacée en une seule opération atomique sur le même système de fichiers. Aucune option -r n’est requise ni acceptée.
Modèles d’utilisation avancés
Utiliser --backup pour éviter une perte de données accidentelle
L’option --backup est l’un des mécanismes de sécurité les plus sous-utilisés de mv. Elle crée une sauvegarde versionnée de tout fichier qui serait écrasé :
mv --backup=numbered config.yml /etc/app/config.yml
Cela produit /etc/app/config.yml.~1~, .~2~, et ainsi de suite pour les écrasements successifs. Dans les scripts de déploiement automatisés, ce modèle fournit un mécanisme de retour arrière léger sans outil de sauvegarde dédié.
Modes de contrôle de sauvegarde :

none / off — Aucune sauvegarde (comportement par défaut sans --backup)
simple / never — Crée toujours une sauvegarde simple avec le suffixe ~

• numbered / t — Crée des sauvegardes numérotées (.~1~, .~2~, …)
• existing / nil — Utilise des sauvegardes numérotées si elles existent déjà ; sinon simple

Déplacements conditionnels avec --update

mv --update /tmp/processed/*.csv /data/archive/

Seuls les fichiers de /tmp/processed/ qui sont plus récents que leurs homologues dans /data/archive/ seront déplacés. Les fichiers avec des horodatages identiques ou plus anciens sont laissés intacts. Cela est particulièrement utile dans les pipelines ETL et les scripts de rotation des journaux où l’idempotence est importante.

Utiliser -t pour une syntaxe adaptée aux scripts

L’option --target-directory inverse l’ordre des arguments, la rendant compatible avec les pipelines xargs et find :

find /var/log -name "*.log.gz" -mtime +30 | xargs mv -t /mnt/cold-storage/logs/

Sans -t, xargs devrait construire la liste d’arguments différemment. Ce modèle est bien plus fiable dans l’automatisation en production.

Combiner --no-clobber avec la sortie verbeuse

mv -nv *.conf /etc/app/conf.d/

Cela déplace tous les fichiers .conf sans écraser les fichiers existants, et affiche chaque déplacement réussi sur stdout. La combinaison est idéale pour des opérations en masse sûres et auditables.

Déplacer des fichiers entre systèmes de fichiers en toute sécurité

Lors du déplacement de fichiers volumineux ou de répertoires entre des points de montage, envisagez ce modèle pour garantir l’intégrité :

rsync -a --remove-source-files /source/path/ /destination/path/ && 
find /source/path -type d -empty -delete

rsync avec --remove-source-files effectue une copie vérifiée avec validation par somme de contrôle, ce que mv ne fournit pas pour les opérations inter-systèmes de fichiers. Utilisez cette approche pour les migrations de données critiques sur les serveurs de production.

Cas d’utilisation pratiques en administration système

Rotation des journaux d’application

mv /var/log/nginx/access.log /var/log/nginx/access.log.$(date +%Y%m%d)
kill -USR1 $(cat /var/run/nginx.pid)

Cela renomme le fichier journal actif et signale à Nginx de rouvrir son descripteur de fichier journal. La combinaison est le fondement de la rotation manuelle des journaux avant que logrotate ne s’en charge automatiquement.

Déploiement atomique de fichiers de configuration

mv --backup=numbered /tmp/nginx.conf /etc/nginx/nginx.conf
nginx -t && systemctl reload nginx

La sauvegarde garantit que la configuration précédente est préservée si la nouvelle échoue à la validation.

Organisation des ressources du serveur web

Sur un serveur exécutant une application web, organisation en masse des fichiers téléversés par type :

mv /var/www/uploads/*.jpg /var/www/uploads/images/
mv /var/www/uploads/*.pdf /var/www/uploads/documents/
mv /var/www/uploads/*.mp4 /var/www/uploads/video/

Ce type de gestion structurée des ressources est courant sur les serveurs hébergeant des sites via un Hébergement Web Mutualisé ou des environnements VPS avec cPanel gérés.

Mise en attente des renouvellements de certificats SSL

Lors de la gestion de certificats renouvelés manuellement, mv avec sauvegarde est un modèle de déploiement sûr :

mv --backup=simple /etc/ssl/certs/domain.crt /etc/ssl/certs/domain.crt.bak
mv /tmp/new_domain.crt /etc/ssl/certs/domain.crt

Pour la gestion automatisée des certificats, associer cela à un service de Certificats SSL correctement configuré élimine entièrement le besoin de rotation manuelle.

Archivage des données de messagerie sur un serveur mail

Sur un serveur exécutant des services de messagerie, déplacement des boîtes aux lettres traitées vers un stockage froid :

mv --update /var/mail/processed/ /mnt/archive/mail/$(date +%Y-%m)/

Cela s’applique directement aux environnements utilisant une infrastructure d’Hébergement Email dédiée où la gestion des boîtes aux lettres est effectuée au niveau du système de fichiers.

mv vs. cp + rm vs. rsync : Quand utiliser lequel

Pièges courants et comment les éviter

Ambiguïté de la barre oblique finale avec les répertoires :

mv directory_a/ directory_b

Si directory_b existe, directory_a est placé *à l’intérieur* de directory_b, résultant en directory_b/directory_a/. Si directory_b n’existe pas, directory_a est renommé en directory_b. Ce comportement surprend de nombreux administrateurs. Utilisez mv -T pour forcer la destination à être traitée comme un chemin de fichier, et non comme un répertoire conteneur.

Expansion de caractères génériques sans correspondance :

mv *.log /archive/

Si aucun fichier .log n’existe, le shell développe *.log en la chaîne littérale *.log, et mv tente de déplacer un fichier littéralement nommé *.log, ce qui échoue avec une erreur déroutante. Utilisez nullglob dans les scripts bash :

shopt -s nullglob
files=(*.log)
[[ ${#files[@]} -gt 0 ]] && mv "${files[@]}" /archive/

Conditions de concurrence dans les environnements concurrents :

Plusieurs processus déplaçant des fichiers depuis un répertoire de file d’attente partagé peuvent provoquer des conflits. Utilisez mv avec un nom temporaire unique, puis renommez de manière atomique :

mv /spool/job_123.tmp /spool/processing/job_123.work

Puisque rename(2) est atomique, ce modèle est sûr pour les files d’attente de travaux sur un seul système de fichiers.

Déplacer des fichiers dont le nom commence par un tiret :

mv -- -oddfile.txt /destination/

Le -- signale la fin des options, empêchant -oddfile.txt d’être interprété comme un indicateur.

Permissions après des déplacements inter-systèmes de fichiers :

mv ne préserve pas les attributs étendus (xattrs), les ACL ou les contextes SELinux sur tous les types de systèmes de fichiers. Après un déplacement inter-systèmes de fichiers, vérifiez avec :

ls -lZ /destination/file
getfattr -d /destination/file

Utiliser mv de manière fiable dans les scripts en production

Pour tout script utilisant mv dans un contexte de production, appliquez ces pratiques sans exception :

#!/usr/bin/env bash
set -euo pipefail

SOURCE="/var/data/export"
DEST="/mnt/nas/backup/$(date +%Y%m%d)"

# Verify source exists
[[ -e "$SOURCE" ]] || { echo "Source not found: $SOURCE" >&2; exit 1; }

# Verify destination is writable
mkdir -p "$DEST"
[[ -w "$DEST" ]] || { echo "Destination not writable: $DEST" >&2; exit 1; }

# Perform move with verbose output for logging
mv -v "$SOURCE" "$DEST/"

• set -euo pipefail garantit que le script se termine en cas d’erreur, de variable non définie ou d’échec de pipe.
• Les vérifications explicites d’existence et d’accessibilité en écriture préviennent les échecs silencieux.
• La sortie verbeuse crée une piste d’audit dans les journaux système.

Matrice de décision : Choisir les bonnes options mv

Points techniques clés à retenir

• mv sur le même système de fichiers est atomique et ne produit aucune E/S disque — c’est une opération sur les métadonnées uniquement via rename(2).
• mv inter-systèmes de fichiers est une séquence copier-puis-supprimer ; traitez-le comme cp pour la planification de la fiabilité.
• Il n’existe pas d’option -r dans GNU mv — les répertoires sont déplacés récursivement par défaut.
• --backup=numbered est la fonctionnalité de sécurité en production la plus sous-utilisée de mv.
• --no-clobber (-n) et --force (-f) sont mutuellement exclusifs ; le dernier spécifié l’emporte.
• Pour les migrations de données critiques inter-systèmes de fichiers, rsync --remove-source-files fournit une vérification par somme de contrôle que mv ne peut pas offrir.
• Citez toujours les variables dans les scripts et utilisez -- pour gérer les noms de fichiers avec des caractères spéciaux.
• Vérifiez les contextes SELinux et les ACL après tout déplacement inter-systèmes de fichiers dans les environnements à sécurité renforcée.

Questions fréquemment posées

mv fonctionne-t-il différemment sur les SSD par rapport aux HDD ?

Pour les déplacements sur le même système de fichiers, non — l’opération est une mise à jour des métadonnées quel que soit le matériel de stockage. Pour les déplacements inter-systèmes de fichiers, les SSD réduisent le temps réel de la phase de copie, mais le comportement logique et les risques sont identiques.

Pourquoi mv prend-il parfois beaucoup de temps même pour un petit fichier ?

Si la source et la destination se trouvent sur des systèmes de fichiers différents — y compris les montages NFS, tmpfs ou des partitions séparées — mv effectue une copie complète. Même un petit fichier déplacé via un montage réseau lent sera lent. Vérifiez avec df -h source destination pour confirmer s’ils partagent un système de fichiers.

mv peut-il être utilisé pour déplacer des fichiers entre des conteneurs ou volumes Docker ?

Pas directement. Les volumes Docker sont des espaces de noms de système de fichiers séparés. mv au sein d’un seul volume fonctionne normalement, mais le déplacement de données entre volumes nécessite des opérations de type cp, généralement via docker cp ou un bind mount partagé.

Que se passe-t-il si mv est interrompu en cours d’opération lors d’un déplacement inter-systèmes de fichiers ?

Le fichier source reste intact jusqu’à ce que la copie soit terminée et que la dissociation réussisse. Si le processus est tué après la copie mais avant la dissociation, les deux copies existent. S’il est tué pendant la copie, le fichier de destination partiel subsiste et la source est intacte. Vérifiez toujours les deux chemins après un mv inter-systèmes de fichiers interrompu.

mv est-il sûr à utiliser dans des tâches cron sans options interactives ?

Oui, à condition d’utiliser explicitement -f ou -n pour supprimer toute invite (qui provoquerait le blocage de la tâche cron), de valider les chemins avant l’exécution, et de rediriger stdout et stderr vers un fichier journal pour l’auditabilité.