Est-ce vraiment utile d'éjecter un lecteur flash en suivant la procédure recommandée au niveau de l'OS
Avant de le retirer ?

Le , par Christian Olivier, Chroniqueur Actualités
Avant de retirer un lecteur flash USB d’un PC, Mac ou mobile compatible avec la fonctionnalité OTG, est-il vraiment nécessaire de respecter la procédure d’éjection recommandée par l’OS du dispositif ? Ne s’agirait-il pas simplement d’une mesure superflue qui ferait perdre du temps à l’utilisateur ?

Les utilisateurs peuvent trouver pénible, voire même inutile dans certains cas, de devoir à chaque fois suivre la procédure d’éjection conseillée de leur lecteur flash qui se termine généralement par un message semblable à celui-ci : « le périphérique peut maintenant être retiré en toute sécurité ». Surtout que, depuis quelques années déjà, les constructeurs ont intégré des ports de connexion (USB type C et USB 3.0 notamment) favorisant les transferts de données à grande vitesse et limitant par la même occasion les éventuelles déconvenues pouvant résulter d'une interruption accidentelle pendant le transfert de données.


Il vous est donc probablement déjà arrivé de retirer physiquement un lecteur flash de son port de connexion sur votre PC, Mac ou appareil mobile compatible sans l’avoir au préalable « éjecté en toute sécurité » comme il se doit depuis le système d’exploitation du dispositif utilisé.

Certains ont même peut-être adopté ce réflexe de « déconnexion physique du lecteur flash » après avoir à de nombreuses reprises fait face à des situations où le flash était utilisé sur un ordinateur ou un appareil mobile « infecté par un malware » et restait impossible à « retirer en toute sécurité » en suivant la voie logicielle recommandée.

En général, ce type de périphérique de stockage externe est muni d’un voyant lumineux qui clignote pour signifier qu’il est en cours d’utilisation et reste éteint ou invariable pour montrer qu’il n’est pas utilisé. Certains ont donc opté pour une méthode assez simple « d’éjection relativement sécurisée » d’un lecteur flash : après avoir reçu une notification faisant étant de l’achèvement de la copie ou du déplacement des données depuis ou vers le lecteur flash, l’utilisateur attend que le voyant d’activité du flash signale que ce dernier est inactif et la déconnecte physiquement quelques secondes plus tard.

Ce n’est certainement pas la méthode la plus sure, mais force est de reconnaitre que dans bien des cas, l’utilisateur ne semble pas pénalisé en suivant cette approche.


Cependant, en agissant de la sorte, l’utilisateur peut recevoir un message d’erreur immédiatement après le retrait du flash ou ultérieurement (à la prochaine tentative de connexion du flash) pour lui signifier que le système de fichier de son flash doit être vérifié ou que l’éjection de ce dernier ne s’est pas bien déroulée. Ce « feedback » varie en général en fonction du système d’exploitation utilisé sur le dispositif hôte, celui sur lequel était connecté le lecteur flash.

Il faut également préciser qu’en ne respectant pas la « procédure d’éjection sécurisée » d’un lecteur flash, l’utilisateur risque de corrompre un fichier ou plusieurs fichiers qui sont stockés dessus ou dans les cas extrêmes de corrompre l’ensemble du périphérique de stockage. Cela pourrait se traduire dans tous les cas par l’altération ou la perte pure et simple des données qui y sont enregistrées.

Ne serait-il pas plus judicieux au final d’adopter des mesures qui garantissent l’intégrité des données d’une manière générale, plutôt que de prendre le risque de les perdre par inadvertance ?

Source : Daring fireball

Et vous ?

Qu’en pensez-vous ?
Comment procédez-vous habituellement pour retirer votre lecteur flash après utilisation ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de ShigruM ShigruM - Nouveau membre du Club https://www.developpez.com
le 24/07/2018 à 7:51
Ne serait-il pas plus judicieux au final d’adopter des mesures qui garantissent l’intégrité des données d’une manière générale, plutôt que de prendre le risque de les perdre par inadvertance ?
ou plus simplement d'utiliser un autres système de fichier supportant très bien ces problèmes comme ne le fais pas fat, exfat ou ntfs mais BRTFS par exemple...
Forcément en utilisant un fs caca on ne peut que courir au désastre, une clé usb en fat32 je lui donne pas cher de sa peau sur la non corruptions des données
Avatar de Neckara Neckara - Expert éminent sénior https://www.developpez.com
le 24/07/2018 à 8:41
Lorsqu'on transfert de gros fichiers (e.g. plusieurs GO), le transfert ne se fait pas instantanément...

Sinon, l'un des objectifs de la procédure, n'est pas uniquement de s'assurer que toutes les opérations E/S sur la clé soient finies, mais que plus aucune application n'utilise la clé.
Notamment, le retrait de la clé, pourrait faire planter l'application quand elle essayera de lire ou d'écrire sur la clé.
Avatar de grunk grunk - Modérateur https://www.developpez.com
le 24/07/2018 à 9:24
Citation Envoyé par Neckara Voir le message
Notamment, le retrait de la clé, pourrait faire planter l'application quand elle essayera de lire ou d'écrire sur la clé.
C'est pas au système d'assurer la stabilité d'une application. C'est au développeur de l'application de gérer le cas d'une écriture/lecture sur un support indisponible (gestion d'exception, etc ..).

Perso sous Windows j'ai jamais déconnecté une clé USB via la "procédure sécurisé" et j'ai jamais eu un problème. Pourtant des clés j'en branche et débranche tous les jours.
Après un transfert je veille effectivement a ce que la led d'activité soit éteinte.

Sous linux en revanche , je débranche toujours "correctement". J'ai déjà corrompue quelques clé sous linux en étant un peu pressé.
Sous ubuntu et debian (je ne sais pas pour les autres) c'est très courant de voir un transfert affiché comme terminé , mais d'avoir la clé qui continue a travailler longtemps après.

Je pense également que la qualité des clés joue pas mal. Toutes les emmerdes que j'ai eu avec des clés ont toujours été sur des clés type "goodies" , jamais sur des clé de marques qui valent 4 fois le prix d'une noname.
Avatar de Neckara Neckara - Expert éminent sénior https://www.developpez.com
le 24/07/2018 à 9:34
Citation Envoyé par grunk Voir le message
C'est pas au système d'assurer la stabilité d'une application. C'est au développeur de l'application de gérer le cas d'une écriture/lecture sur un support indisponible (gestion d'exception, etc ..).
Sauf que si tu as besoin d'un fichier pour continuer tes opérations, et que tu ne trouves pas ton fichiers, tu ne peux pas faire autre chose que planter.

Alors tu peux avoir un joli message qui s'affiche, mais cela ne change rien quant au fait que ton application va stopper sa tâche en cours.
Avatar de hotcryx hotcryx - Membre extrêmement actif https://www.developpez.com
le 24/07/2018 à 10:02
"Est-ce vraiment utile d'éjecter un lecteur flash en suivant la procédure recommandée au niveau de l’OS"

Clair! Sous Linux c'est nécessaire de faire un umount du device, s'il n'était pas monté en Read Only.

fsck est votre ami si vous ne le faites pas
Avatar de tomlev tomlev - Rédacteur/Modérateur https://www.developpez.com
le 24/07/2018 à 10:50
Certains devices ne proposent pas l'option "éjecter en toute sécurité". L'autre jour j'avais branché ma GoPro à l'ordinateur, j'ai supprimé quelques fichiers qui étaient dessus en en laissant d'autres, puis je l'ai débranchée (sans éjection sécurisée puisque l'option n'apparaissait pas). Résultat : plus aucun fichier sur ma carte SD... L'espace est toujours occupé, mais les fichiers n'apparaissent plus. Du coup je me dis que cette "procédure sécurisée" n'est sans doute pas totalement inutile...
Avatar de SofEvans SofEvans - Membre expérimenté https://www.developpez.com
le 24/07/2018 à 11:40
Euuuh, pour l'histoire des clef corrompues, c'est tout simplement pas à cause du buffering ?

Lorsque l'on mount une clef, on peut choisir "sync" dans ses options (c'est "async" par défaut, pour des raisons de perf') : cela permets d'être sûr que les opérations I/O sont bien terminées lorsque l'OS le dit.
Si la clef est en "async", alors tout le fichier n'est pas forcement sur la clef lorsque l'OS dit qu'il a terminé ses opérations I/O : c'est lors du umount explicite que la dernière partie du fichier encore dans le buffer est écrite définitivement sur la clef.

Perso, je suis toujours en "sync", j'arrache toujours mes clef lorsque j'ai fini mes opérations et jamais eu un problème (Debian8).
Bon, je sais que c'est pas à faire, mais si la clef est un tant soit peu de qualité, elle gère très bien la coupure "brutale" d'alimentation.
Avatar de sinople sinople - Membre chevronné https://www.developpez.com
le 24/07/2018 à 12:09
Si il y a une chose dont je suis persuadé c'est qu'en enlevant ses clés USB à l'arrache on a de forte chance d'avoir une fois un problème à moyenne échéance. Je ne sais pas si la cause c'est la fiabilité des clés USB en général ou spécifiquement le débranchement sauvage.

D'expérience, je sais juste qu'il faut mieux utiliser ces périphériques pour le transport de fichier par copie plutôt qu'en tant que stockage "primaire" de ces documents de travail. Mais c'est une autre histoire.
Avatar de abriotde abriotde - Membre éprouvé https://www.developpez.com
le 24/07/2018 à 13:40
J'ai déjà corrompue quelques clé sous linux en étant un peu pressé.
Sous Linux comme dit plus haut, si la clef est sous un FS Linux (Ext4 ou BTRFS), il n'y a pas de problème car il y a la journalisation. La clef ne sera jamais corrompu mais si l'on a retiré la clef avant que le fichier soit complètement écris c'est certains que le fichier (et seulement celui-ci) sera corrompu. Sous Linux (je connais pas Windows), le fichier est écris quand l'OS a le temps c'est pourquoi cela peut-être long (c'est une question d'optimisation des ressources).

Par contre il est un cas ou il n'est jamais utile de débrancher correctement c'est si l'on n'a fais que de la lecture de fichiers.

Personnellement je débranche proprement que si j'ai écris des données sensibles (un rapport, écriture de clé bootable, données que je vais effacer du disques dur...)
Avatar de nirgal76 nirgal76 - Membre expérimenté https://www.developpez.com
le 24/07/2018 à 14:30
Ben sous Windows, les chances de corruptions va aussi dépendre si le cache en écriture est mis non ? (par défaut désactivé pour les clés USB, tout du moins c'était comme ça sur mon Windows).
Bon après, si les gens peuvent pas attendre 3 secondes pour enlever une clé, ça devient grave (et ça le devient en fait).
Contacter le responsable de la rubrique Accueil