Lorsqu’on formate un périphérique amovible, le choix du système de fichiers est dicté par des contraintes particulières, en particulier la possibilité de le lire depuis des systèmes d’exploitation moins polyvalents que GNU/Linux. Les systèmes de propriétés et de permissions peuvent également être un obstacle dans un tel contexte, puisqu’on peut se retrouver à ne pas pouvoir modifier un fichier créé depuis un autre ordinateur avec un utilisateur différent de celui qu’on utilise.
Voici donc un petit état des lieux.
Sommaire
Résumé
Si vous comptez utiliser votre périphérique uniquement depuis GNU/Linux et que vous aimez jouer en ligne de commande, formatez-le en ext4 s’il s’agit d’un disque dur, ou en F2FS s’il s’agit d’un périphérique flash (clef USB, SSD ou carte SD).
Sinon, s’il s’agit d’une clef USB où vous n’envisagez pas de stocker des fichiers de plus de 4 Gio, formatez-la en FAT32.
Sinon, si vous comptez utiliser votre périphérique amovible depuis d’autres ordinateurs qui ne tournent pas sous GNU/Linux, formatez-le en exFAT.
Voici un tableau récapitulatif des caractéristiques des principaux systèmes de fichiers utilisables sur périphérique amovible. Par « unixeries », j’entends le support de fichiers spéciaux (surtout les liens symboliques, mais également les nœuds de périphérique, les sockets Unix et les tubes nommés) et les notions de propriétaire et de permissions. Je mentionne également la possibilité de créer des fichiers sans propriétaire défini ou d’émuler cela à coup d’ACL, pour éviter des problèmes de permissions entre différents ordinateurs (voir le paragraphe Notes).
| Fonctionnalité | Ext2/3/4 | F2FS | FAT32 | NTFS | exFAT | UDF |
|---|---|---|---|---|---|---|
| Lisible sous Linux | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Lisible sous MacOS | ✓ | ro | ✓ | ~ | ||
| Lisible sous Windows | ✓ | ✓ | ✓ | ✓ | ||
| Unixeries | ✓ | ✓ | ✓ | |||
| Fichiers sans propriétaire | via ACL | via ACL | ✓ | ✓ | ✓ | ✓ |
| Adapté aux flash | ✓ | |||||
| Ouvert ou documenté | ✓ | ✓ | ✓ | ✓ | ✓ | |
| Brevets problématiques | ⚠ |
Notes
Le scénario est le suivant : sur un premier ordinateur, en tant qu’utilisateur mrobin:1042, vous créez un fichier sur une clef USB ; après l’avoir branchée sur un autre ordinateur, vous essayez de modifier ce même fichier en tant qu’utilisateur roxane:1001, et vous vous prenez une belle erreur parce qu’il n’est modifiable que par l’utilisateur numéro 1042.
Ext2, ext3, ext4
Ces systèmes de fichiers, créés pour Linux, sont également lisibles de façon native sous FreeBSD. Sous MacOS et Windows, il faut installer un pilote spécifique, ce qui est assez rédhibitoire pour un périphérique amovible.
En matière de fonctionnalités, ces systèmes de fichiers implémentent évidemment toutes les notions unixiennes.
Pour les périphériques à base de flash, il est pertinent de créer un système de fichiers sans journal, avec mkfs.ext4 -O ^has_journal.
Création d’un système de fichiers :
mkfs.ext4 -O ^has_journal -L "Clef USB de Cyrano" /dev/sdc1
F2FS
Le Flash-Friendly File System a été créé par Samsung pour les cartes mémoires de leurs téléphones sous Android, donc pour Linux. Il a donc été conçu pour être utilisable sur des périphériques flash, y compris des clefs USB ou des SSD.
S’agissant d’un système de fichier conçu pour Linux, il prend évidemment en charge toutes les subtilités unixiennes.
Création d’un système de fichiers :
mkfs.f2fs -l "Clef USB de Cyrano" /dev/sdc1
FAT32
FAT32 est un système de fichier assez ancien, créé par Microsoft pour Windows 95. Techniquement, ce système de fichiers est utilisé avec une bidouille nommée VFAT, pour permettre d’utiliser des noms de fichiers un peu plus libres que le format 8.3 (huit caractères, puis un point, puis trois caractères) initialement prévu.
Ce système de fichiers est assez ancien pour ne plus être couvert par des brevets encore valides. Il a l’avantage d’être pris en charge partout, c’est pourquoi il est largement utilisé sur les clefs USB et cartes SD.
Il est en revanche franchement déficient, avec des limitations majeures :
- conçu pour MS-DOS et Windows 95, il ne permet pas de stocker des fichiers spéciaux (liens symboliques, périphériques, sockets et tubes nommés), et n’implémente aucune notion de propriété, bien qu’il fournisse une notion rudimentaire de permissions ;
- le nom de volume ne peut pas dépasser 11 caractères ;
- il ne permet pas de stocker de fichiers de plus de 4 Gio.
Création d’un système de fichiers :
mkfs.fat -n "Clef Cyrano"
NTFS
NTFS est un système de fichiers créé par Microsoft pour Windows NT. Il est utilisé comme système natif par les systèmes Windows actuels.
Il est également lisible nativement sous MacOS, mais il faut installer un pilote propriétaire spécifique pour pouvoir le monter lecture-écriture. Sous GNU/Linux, et visiblement sous FreeBSD, il est pris en charge en lecture-écriture par le pilote en espace utilisateur ntfs-3g.
Ce système de fichier n’implémente pas les subtilités unixiennes de fichiers spéciaux, de propriété et de permissions. Il dispose d’un système de propriété et de permissions à la sauce Windows, normalement inutilisés sous Linux.
Création d’un système de fichiers :
mkfs.ntfs -L "Disque dur externe de Cyrano" /dev/sdc1
exFAT
exFAT est le dernier né de la famille de fichiers FAT de Microsoft, qui règle quelques limitations de FAT32, notamment le stockage des gros fichiers.
Ce système de fichier fermé et soumis à des brevets, mais Microsoft en a finalement publié les spécification et a donné ses brevets à l’Open Invention Network en 2019. Il s’agit donc maintenant d’un format ouvert sans brevets qui pourraient poser problème. Cela a notamment permis l’intégration d’un pilote exFAT dans le noyau Linux.
En pratique, ce système de fichier est pris en charge par tous les systèmes d’exploitation relativement récents, et il est d’ailleurs utilisé sur les cartes SD de grande capacité.
Il souffre de limitations héritées de FAT32, à savoir :
- il ne permet pas de stocker des fichiers spéciaux et n’implémente pas les notions de propriété et de permissions unixiennes ;
- le nom de volume ne peut pas dépasser 11 caractères.
Création d’un système de fichiers :
mkfs.exfat -L "Clef Cyrano" /dev/sdc1
UDF
L’Universal Disk Format est un système de fichiers normalisé par l’ISO, et est surtout utilisé sur les DVD. Il est, pour cette raison, pris en charge partout, et tout à fait utilisable sur des supports non optiques, à une époque je le recommandais même pour les clefs USB.
Malheureusement, ce n’est pas si parfait :
- sous MacOS, la dernière fois que j’avais pu l’essayer, on ne pouvait monter une clef USB formatée en UDF que depuis un terminal ;
- sous Linux, le support UDF est assez rudimentaire : on constate parfois des débits d’écriture pitoyables, et il n’existe pas de
fsck.udfpar exemple.
C’est dommage, parce que ce système de fichiers a pas mal d’avantages :
- il prend en charge toutes les subtilités unixiennes ;
- il dispose d’une notion de fichier au propriétaire non spécifié, qui sous Linux apparaît comme appartenant à celui qui a effectué le montage, ce qui est parfait pour un support amovible.
Création d’un système de fichiers :
mkudffs -l "Clef USB de Cyrano" /dev/sdc1
Aller plus loin
- UDF sur clefs USB (59 clics)
- ACL pour les supports amovibles (65 clics)
- F2FS (55 clics)
- ExFAT (38 clics)
# Correction pour NTFS
Posté par Pinaraf . Évalué à 10. Dernière modification le 23 avril 2021 à 18:57.
Un pilote NTFS complet avec lecture/écriture est en cours d'intégration dans le noyau.
Il n'a pas passé la fenêtre du 5.12, peut-être en 5.13.
La série de patch en est à la version 27 : https://lore.kernel.org/lkml/20210402155347.64594-1-almaz.alexandrovich@paragon-software.com/
[^] # Re: Correction pour NTFS
Posté par xylphute . Évalué à 2.
Ntfs est possible en écriture sous macOS. Même principe que Linux il faut utiliser ntfs-3g
[^] # Re: Correction pour NTFS
Posté par Pinaraf . Évalué à 3.
Oui mais est-ce-que ntfs-3g est installé sur la majorité des MacOS ? Alors que la majorité des distributions Linux Desktop vont l'intégrer.
Si on compte l'installation de logiciels tiers, non intégrés de base, il faut changer les résultats pour Windows aussi puisque des pilotes pour ext sont disponibles…
[^] # Re: Correction pour NTFS
Posté par xylphute . Évalué à 3.
Alors la présence de ntfs-3g sur mac… Honnêtement je ne sais pas si il est très répandu ou pas.
Apres je suis d'accord si on prend ce qui est natif dans les OS… Le tableau est correct.
Mais pour linux, ntfs-3g n'est pas présent par défaut dans toutes les distributions également.
Quant à windows effectivement on peut ajouter du ext, mais je n'ai jamais trouvé ces solutions propres. Quand on a l'écriture d'ext sous windows on peut faire de gros dégâts dans le système Linux contenu.
[^] # Re: Correction pour NTFS
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
J'avais utilisé il y a plus de 20 ans ce logiciel Windows qui permettait d'aller dans le disque ext. C'est très risqué en cas de fausse manœuvre et pire, c'est un gigantesque trou de sécurité.
Depuis 2000, je n'ai plus de Windows installé, je m'en porte fort bien ! Je n'ai donc plus aucun besoin de ce logiciel.
[^] # Re: Correction pour NTFS
Posté par iXô (Mastodon) . Évalué à 3.
Petite correction, il n'est pas nécessaire d'ajouter quoi que ce soit pour que macOS puisse écrire sur du NTFS, il suffit de modifier le fichier /etc/fstab.
Voir ce lien : https://gist.github.com/CharlesThierry/7305166b208d6f6cdd37962761d5ac23
L'étape UUID, il est tout à fait possible de passer par le LABEL=nom et tout se passe correctement.
La petite subtilité, est que l'option nobrowse (qui semble nécessaire par expérience) fait que le Finder n'affiche plus le périphérique, mais il "suffit" d'aller dans /Volumes et on trouve notre périphérique, monté en écriture, et qui fonctionne très bien.
[^] # Re: Correction pour NTFS
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Très bonne nouvelle !
Pour info, mais vous l'aurez déjà deviné, mon tableau indique ce qui est faisable directement, ou du moins très facilement, avec les différents systèmes d'exploitation. Autant que je sache, ntfs-3g est déjà installé, ou très facile à installer, sur les distributions GNU/Linux majeures, mais n'est pas préinstallé sous MacOS.
# Et quand ce n’est pas un ordinateur ?
Posté par SlowBrain (site web personnel) . Évalué à 10.
Bonne information à la quelle il manque pour moi une catégorie de nos vies courantes numériques : Les appareils qui ne sont pas les ordinateurs.
Ces matériels, qui reviennent à de l’informatique embarqué n’implémentent, suivant le soin des fabricants, qu’une partie des protocoles de gestion de ces périphériques. Ce qui pose parfois quelques problémes.
Pour ceux qui enregistrent des données, tel que les appareils photos numériques, ils proposent souvent une option de formatage pour utiliser le format qui leur va bien, et je leur dédie une ou plusieurs carte mémoire suivant les usages.
L’ordinateur ne les utilisant finalement qu’en lecture quand l’appareil le permet, ce qui évite de le perturber.
L’usage ou cela est plus flou est les appareils qui vont lire les données écrite par un ordinateur : Un lecteur de musique qui va lire les morceaux à partir d’une clef USB (Autoradio, chaine HiFi, lecteur portable, …).
Ici c’est bien l’ordinateur qui va fournir les informations, en toute connaissance des protocoles, et le périphériques qui va les lire, avec parfois ces particularités.
Je prendrais l’exemple de l’autoradio qui équipe ma voiture (que dans un soucis d’écologie j’utilise de façon de plus en plus raisonnée - Mais c’est un autre débat).
Pour éviter les problèmes de lecture j’ai du appliquer les principes suivants :
- Preparer et écrire en une seule fois linéaire les morceaux. Un espace de stockage qui est fragmenté pose des soucis de lecture des morceaux.
- Utiliser un format de fichier le plus passe partout possible : Fat32 je crois …
- Bloquer le périphérique en lecture seul. Probablement un bug de ce matériel spécifique, mais au bout d’un certain nombre d’heure d’utilisation le système se bloque. Restaurer une image identique sur le même périphérique de stockage résous le probléme.
Sur ce point un lecteur de carte SD USB, avec une carte SD bloqué en lecture seul as résolu le problème.
Je suppose que le système doit d’une façon ou d’une écrire sur le périphérique au point de se perturber lui même.
Hors astuce de la carte SD … je ne saurais comment faire.
Mais ce sujet mériterais probablement bien plus que mes bafouilles matinales.
[^] # Re: Et quand ce n’est pas un ordinateur ?
Posté par barmic 🦦 . Évalué à 6.
Ça me fait penser que moi qui ai l'habitude d'utiliser UDF sur mes clefs, j'ai fais crasher violemment une imprimante pro en lui branchant ma clef USB.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et quand ce n’est pas un ordinateur ?
Posté par Faya . Évalué à 7.
OK c'est un autre débat mais je ne comprends pas le lien entre l'utilisation de l'autoradio et l'écologie. C'est pour ne pas utiliser la batterie (mais sauf erreur elle est rechargée par l'alternateur quand on roule, sauf peut-être sur les modèles électriques) ?
[^] # Re: Et quand ce n’est pas un ordinateur ?
Posté par vv222 . Évalué à 10.
M’est avis que ce n’est pas de l’autoradio dont il est question ici, mais de la voiture qui est autour ;)
[^] # Re: Et quand ce n’est pas un ordinateur ?
Posté par Faya . Évalué à 5.
OK, j'ai honte… Je relis la phrase et je ne sais pas trop comment j'ai fait pour comprendre de travers. Vais utiliser la pirouette imbattable : "je sais, c'était de l'humour".
[^] # Re: Et quand ce n’est pas un ordinateur ?
Posté par Stéphane Ascoët (site web personnel) . Évalué à 1.
Pendant une demi-seconde j'ai pensé la même chose que toi !
Dommage que le tableau apparaisse très mal et qu'il n'y ait pas non plus l'indication des versions. Ça mériterait d'être sur un wiki, comme du temps du wiki du centre de ressources informatiques du pays de Brest
Du coup maintenant j'ai entamé un tableau des FS gérés par mes supports, ordinateurs et OS dans Gnumeric, fort sympathique et enthousiasmant, mais que je ne pense jamais à compléter
[^] # Re: Et quand ce n’est pas un ordinateur ?
Posté par SlowBrain (site web personnel) . Évalué à 6.
Je confirme que c’est bien le véhicule dont je limite l’utilisation :)
Dans l’absolu utiliser l’autoradio impliquera plus de consommation de carburant, via les multiples jeux de conversion d’énergies.
Je ne sais pas quel est l’impact sur la consommation, mais je doute qu’il soit élevé, et qu’il doit y avoir d’autres méthodes plus performantes que de couper la musique, pour limiter sa consommation au volant.
[^] # Re: Et quand ce n’est pas un ordinateur ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Dans un véhicule à moteur thermique, en effet, le moindre watt électrique utilisé provient de la combustion du carburant, via l'alternateur, dont la résistance à la rotation augmente d'autant lorsqu'on consomme du courant. :-)
Le seul accessoire qui n'augmente pas la consommation, c'est le chauffage !
[^] # Re: Et quand ce n’est pas un ordinateur ?
Posté par barmic 🦦 . Évalué à 3.
Hum ? Il y a une augmentation de la fréquence de rotation pour aligner la production à la consommation, mais je suis surpris que ça ai une influence directe sur le champ magnétique de la bibine.
De plus je ne serais pas aussi catégorique parce que je ne sais pas si le couplage consommation/production et si bien aligné que ça. Est-ce qu'il n'y a pas une surconsommation générale qui est diminuée lors de l'utilisation de l'autoradio ? Est-ce que l'autoradio ne consomme pas simplement une légère partie de l'énergie habituellement envoyée à la batterie ?
Je suis très loin d'avoir le niveau en électricité et dans le fonctionnement d'une voiture pour vérifier.
Par contre c'est un épiphénomène, la consommation lié aux phares, autoradio, etc doit être minime face à l'énergie nécessaire pour déplacer 1t sur des dizaines de km. Ce n'est qu'une démarche intellectuelle et pas une démarche écologique.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et quand ce n’est pas un ordinateur ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Ah, je ne sais pas, en tout cas, la notice de ma voiture, une Twingo 2, indique ceci :
Si l'usage de l'autoradio entraîne une surconsommation, je suis d'accord sur le fait qu'elle est évidemment minime, comparée à la consommation de base pour rouler, et à celle des feux ou du climatiseur.
Sur une bicyclette équipée d'une dynamo de moyeu, je peux vous confirmer qu'allumer les feux entraîne une résistance à la rotation de la roue concernée. Avec les feux éteints, la dynamo crée simplement un effet de crantage de la rotation, mais pas de résistance notable.
[^] # Re: Et quand ce n’est pas un ordinateur ?
Posté par SlowBrain (site web personnel) . Évalué à 7.
Oui, dans un véhicule thermique, plus on demande d’électricité, plus cela consomme du carburant.
De façon générale l'électricité est produite est consommé sur le même instant (d'autant plus à l'échelle d'une voiture)
Une génératrice électrique (ici notre alternateur, mais c’est aussi le cas d’une dynamo) va transformer une vitesse de rotation et un «couple» qui constitue une puissance mécanique en une puissance électrique décomposé en tension et courant.
La tension dépend de la vitesse de rotation de la génératrice.
Les voitures modernes ayant des régulateurs qui stabilisent cette tension autour de 13,6 volts (même si on parle souvent de « 12 volts » dans les voitures).
Si la tension est fixée par le générateur, le courant est lui consommé par les appareils (plus ou moins gourmands).
Le courant va agir sur le couple. Plus on demande de courant à une génératrice, plus il va y avoir une résistance à la rotation.
Le moteur, ici thermique (mais c’est la même chose avec un cycliste et sa dynamo), ayant besoin de fournir plus de puissance pour maintenir la vitesse, et donc la tension électrique.
--
Moteur tournant, on peut se passer de batterie dans une voiture thermique.
Elle n’est à ce moment-là qu’un consommateur comme un autre, tant qu’elle n’a pas fait le plein. L’alternateur est suffisant pour fournir l’ensemble de la consommation électrique du véhicule.
Pourquoi avoir une batterie alors ?
Pour démarrer le moteur !
Un moteur thermique n’est pas autonome pour se lancer, il faut un autre système pour lui faire faire ces premiers tours.
C’est le Kick-Starter sur les motos, le cordon à tirer sur les tondeuses ou la manivelle sur les voitures, remplacé par le bien plus pratique moteur électrique… qui as besoin d’électricité qu’il va puiser dans la batterie.
Accessoirement cette batterie peux servir à alimenter du matériel électronique à bord quand le moteur est arrête.
[^] # Re: Et quand ce n’est pas un ordinateur ?
Posté par Pinaraf . Évalué à 5.
Pas que.
La voiture est remplie d'accessoires et de moins-accessoires dépendant de l'électrique : essuie-glace (niveau élec c'est minable), phares (déjà un peu moins), vitres électriques, direction assistée (selon les modèles, mais ça c'est pas accessoire)…
Et du coup, petit vécu sur une voiture tchutchutpademarque : de nuit, en prenant un virage, la direction assistée s'est soudain coupée et je me suis en plein virage retrouvé en direction insistée. Après 2 aller-retour au garage où diverses pièces ont été changées, j'ai fini par trouver une solution pour qu'ils puissent reproduire le problème à l'arrêt, et donc je leur ai déposé le véhicule avec comme mission "vous me rendez la voiture sans ce comportement" : à l'arrêt, moteur allumé (mais pas au ralenti, il fallait un certain nombre de tours/min de mémoire), autoradio allumé, mettre le volant en butée, et avec les fenêtres fermées actionner la fermeture des fenêtres. C'est le chemin le plus court pour maximiser la consommation électrique, et ça faisait sauter immédiatement la direction assistée.
Et le coupable était la batterie qui ne faisait plus son taf correctement dans ces conditions.
Depuis, plus de tchutchutpademarque…
[^] # Pollueur
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2. Dernière modification le 26 mai 2021 à 18:33.
Ça n'est vrai que pour les moteurs à auto ignition du mélange carburant/comburant ; en pratique les moteurs à cycle ~Diesel où c'est la pression engendrée par la remontée du piston qui déclenche la combustion. Les moteurs à cycle ~Beau de Rochas eux utilisent des bougies qui ne s'allument généralement que si la batterie leur fournie la tension nécessaire. D'où le titre pollueur, bien dans l'esprit du temps, stigmatisant, mais pas très sérieux : d'un point de vue strictement énergétique, il semblerait que les moteurs au gazole soient plus efficaces que leurs homologues au sans plomb pour nos véhicules automobiles.
PS : Pour avoir expérimenter les deux, je recommande la panne électrique sur véhicule Diesel. Détectée en cours de trajet elle permet de se rendre chez le garagiste de son choix sans passer par l'onéreuse case dépanneuse. Alors que le moteur qui se coupe subitement sur l'autoroute…
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Et quand ce n’est pas un ordinateur ?
Posté par Milo . Évalué à 2.
Après un hiver avec une Toyota, je m'aperçois que c'est faux sur une hybride. Il est nécessaire de faire tourner le moteur thermique pour chauffer la voiture en début de trajet … (ça se calme par la suite).
d'où une certaine surconsommation bien sensible sur les trajets courts.
[^] # Re: Et quand ce n’est pas un ordinateur ?
Posté par Stéphane Ascoët (site web personnel) . Évalué à 1.
Et d'une façon générale, je ne suis quand même pas sûr que le chauffage ne consomme vraiment rien.
Pour les alternateurs de moyeu de vélos, la différence est nette avec une Son, réputée celle qui en a le moins, mais j'observe aussi des écarts d'un modèle à l'autre(ou j'ai plutôt l'impression que c'est lié au montage sur la roue/le vélo)
Par contre bizarrement, il parait qu'un des modèles phares de chez Shimano est plus fluide avec la lampe allumée qu'éteinte !
[^] # Re: Et quand ce n’est pas un ordinateur ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7. Dernière modification le 26 avril 2021 à 17:41.
Sur un véhicule à moteur purement thermique, le chauffage est gratuit. En fait, le moteur chauffe naturellement et a toujours besoin d'être refroidi. Il y a pour cela un circuit de refroidissement, dans lequel circule de l'eau, qui devient brûlant après avoir refroidi le moteur, puis passe dans un radiateur, où elle est refroidie par l'air ambiant qui circule naturellement lorsqu'on roule, et qui circule de force avec l'aide d'un ventilateur si ça ne suffit pas.
Lorsqu'on allume le chauffage, l'air qui a servi à refroidir l'eau du circuit de refroidissement est simplement envoyé dans l'habitacle. C'est gratuit, en revanche ça ne fonctionne pas immédiatement après démarrage, il faut que le moteur ait déjà chauffé un peu.
[^] # Re: Et quand ce n’est pas un ordinateur ?
Posté par SlowBrain (site web personnel) . Évalué à 7.
Si on veut être puriste, c’est la production de chaleur sur un véhicule thermique qui ne coûte rien. La chaleur étant un déchet de fonctionnement que l’on peut recycler pour faire du chauffage de l’habitacle (et c’est même un problème dans les voitures électriques, dont le moteur crée moins de déchets en chaleur).
Mais même si on reste sur un chauffage simple sans électronique de contrôle (et de régulation), il reste malgré tout la consommation électrique de la ventilation pour diffuser la chaleur dans l’habitacle.
# Résumé
Posté par Colin Pitrat (site web personnel) . Évalué à 7.
Pourquoi pas exFAT dans ce cas aussi? Je ne vois pas l'avantage de FAT32 par rapport a exFAT
[^] # Re: Résumé
Posté par Pinaraf . Évalué à 10. Dernière modification le 24 avril 2021 à 11:01.
C'est parce que le tableau tente de rendre binaire ce qui ne l'est pas.
exFAT n'est supporté sous Linux sans FUSE que depuis le noyau 5.4, novembre 2019, donc dans les distributions de 2020 et ultérieur. Avant, il fallait installer un paquet supplémentaire, donc le support n'était pas garanti.
De plus, il ne faut pas oublier tout le matériel à la con qui existe : auto-radios ou lecteurs de musique, imprimantes, appareils divers et variés acceptant des clés USB fonctionnant avec des OS inconnus… Eux ne supporteront en général que le FAT32.
[^] # Re: Résumé
Posté par nekopep . Évalué à 9.
Alors sous linux je trouve fsck.vfat beaucoup plus robuste que celui de exfat.
En FAT32 le driver est super éprouvé, celui de exfat semble encore un peu jeune. Par exemple il m'est arrivé de devoir faire un scandisk sous windows pour récupérer des fichiers sur une sdcard là ou linux ne relevait aucun problème.
[^] # Re: Résumé
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Parce que FAT32 est lisible absolument partout, même sur des trucs conçus il y a trente ans. ExFAT est lisible sur à peu près tout les trucs pas trop anciens, ça peut faire une différence.
# Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: FAT32 : parfois c'est 2Go
Posté par Pierre Jarillon (site web personnel) . Évalué à 5.
C'est un problème de codage des entiers sur 32 bits. Généralement on garde un bit pour le signe. Il ne reste plus que 31 bits ce qui permet de compter jusqu'à 2 147 483 648 ce qui fait bien 2 Go.
Il y a bien des langages qui permettent de travailler avec des
unsigned integermais ce n'est pas toujours possible. L'intérêt est de pouvoir faire facilement des calculs et our cela les entiers signés sont bien préférables.[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: FAT32 : parfois c'est 2Go
Posté par Pol' uX (site web personnel) . Évalué à 4.
Ou bien 2Gio. Car 2Go ça fait normalement bien 2 000 000 000. :)
Adhérer à l'April, ça vous tente ?
[^] # Re: FAT32 : parfois c'est 2Go
Posté par Stéphane Ascoët (site web personnel) . Évalué à -7.
En effet, ça vaudrait le coup d'indiquer ce qui est vrai en pratique et non en théorie. Par contre, je suis déçu par la soumission de la communauté libriste à ce scandaleux changement de l'unité de mesure, tout ça pour faire plaisir aux constructeurs ! C'est comme si on décidait de changer le système métrique(remarquez que dans "le syndrome du Carambar" de Gaël Naizet…)!
[^] # Re: FAT32 : parfois c'est 2Go
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
Il n'y a aucun changement du système métrique, un giga ça a toujours été un milliard tout rond.
[^] # Re: FAT32 : parfois c'est 2Go
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
https://fr.wikipedia.org/wiki/Syst%C3%A8me_international_d%27unit%C3%A9s
https://fr.wikipedia.org/wiki/Pr%C3%A9fixes_du_Syst%C3%A8me_international_d%27unit%C3%A9s#Cas_de_l'informatique
(Commission électrotechnique internationale, norme 60027-2, 1998)
[^] # Re: FAT32 : parfois c'est 2Go
Posté par Stéphane Ascoët (site web personnel) . Évalué à -2.
Ben oui, c'est exactement ce que je dis. Ce n'est pas parce qu'ils le préconisent qu'ils ont raison
[^] # Re: FAT32 : parfois c'est 2Go
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Gibi ça n'est bon que pour les Shadoks. Dommage qu'ils n'aient pas profiter du cas binaire pour créer le préfixe gigo qui aurait fait l'unanimité des amateurs de jeux de mots, des fans de film de SF des années 80, et de bon nombre de religions monothéistes où sa consommation annuelle est une tradition millénaire.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: FAT32 : parfois c'est 2Go
Posté par Stéphane Ascoët (site web personnel) . Évalué à 0.
Doc E. Brown parlant en binaire, pas mal comme geekitude ultime !
# ext4 vs f2fs sur flash / ssd
Posté par raphj . Évalué à 6. Dernière modification le 24 avril 2021 à 12:53.
Il me semble que beaucoup de téléphones Android viennent avec leur mémoire interne / carte mémoire formatée en ext4. C'est aussi le format utilisé sous Mobian pour la mémoire interne du PinePhone.
J'avais vaguement regardé des comparaisons entre ext4 et f2fs il y a quelques temps pour un usage sur téléphone Android et je n'ai jamais réussi à arriver à une conclusion claire sur lequel est le mieux. D'ailleurs, j'ai l'impression que si c'était si claire, les téléphones Android viendraient quasi systématiquement avec un formatage f2fs, non ?
Mon dernier téléphone Android était vendu avec sa partition data formatée en f2fs, mais un bug dans son pilote f2fs a donné du fil à retordre aux gens qui faisaient des ROMs custom pour ce téléphone (bug impliquant des problèmes de compatibilité, pas de stabilité de perf, de mémoire). J'ai utilisé LineageOS avec ext4 sur ce téléphone et n'ai pas perçu de différence de performance à l'utilisation. Quant à l'usure, je n'ai aucune donnée.
D'après des choses écrites en 2017, ext4 était plus stable à cette époque que f2fs, dans le sens où plus de patches changeaient des grosses parties du fonctionnement de f2fs comparé à ext4, est-ce que ce ça a évolué, 4 ans plus tard ?
D'après un article de Phoronix en mars 2020 pour une utilisation qui a l'air orientée serveur, f2fs bat ext4 sur pas mal de benchmarks mais globalement ext4 sort très légèrement gagnant côté performances sur SSD.
Du coup, je ne sais toujours pas.
Dans tous les cas, ça ne mange pas de pain de rajouter noatime et nodiratime aux options de montage du système de fichier pour éviter des écritures à chaque accès.
[^] # Re: ext4 vs f2fs sur flash / ssd
Posté par cg . Évalué à 2.
Dans l'article mis en lien, ext4 remporte tous les comparatifs.
[^] # Re: ext4 vs f2fs sur flash / ssd
Posté par raphj . Évalué à 3.
Pas vraiment (pages 2 et 3) :
[^] # Re: ext4 vs f2fs sur flash / ssd
Posté par cg . Évalué à 2. Dernière modification le 25 mai 2021 à 20:41.
Ah, quelle buse je fais, comme le lien était sur la page 4, j'ai pas vu les pages d'avant :-o .
Bon, la conclusion de l'article reste : "At the end of the day […] EXT4 came out to being just 2% faster than F2FS".
# Remarques
Posté par barmic 🦦 . Évalué à 4.
J'ai quelques remarques :)
unixeries
Autant les liens symboliques je peux voir l'intérêt autant tout le reste je ne pense pas que ça ai du sens dans le cadre d'un périphérique amovible que tu cherche à passer d'un système à un autre, mais tu as oublié une unixerie qui peut être très importante : les propriétés étendues (xattrs dans la langue de molière) et pour le coup je sais qu'il y a eu des évolutions récentes qui ne sont pas arrivées immédiatement dans tous les fs (je crois que c'est une augmentation de la taille limite).
UDF
La dernière fois que j'ai formaté une clef usb en UDF (c'est le format que j'utilise de base), il m'a était notifié par l'outil que MacOS n'aime pas avoir un périphérique UDF avec une table de partition. Je ne sais pas ce qu'il en ai (j'utilise une debian stable ça a peut être évolué ces 2 dernières années).
fsck
Tu reproche à udf de ne pas avoir de fsck, mais est-ce que le fsck d'ext4 est opérant si on a désactivé le journal ? Autre point ext* aime bien avoir un fsck régulier ce qui n'est pas forcément pratique pour un périphérique amovible.
btrfs
Quitte à partir sur de l'ext4 sans journal peut être que btrfs peut être une bonne idée ? Il aura globalement les même problèmes, mais il n'a de base pas de journal.
fscrypt
Une fonctionnalité qui peut par contre faire sortir du lot ext4 et f2fs c'est le support de fscrypt. Ça permet de chiffrer les données, mais contrairement à un chiffrement au niveau bloc device (ce que fais dm-crypt) ici il va être possible de chiffrer des dossiers. C'est intéressant pour pouvoir ne chiffrer qu'un dossier et ne pas avoir à créer différentes partitions pour ça (ce qui fait perdre en souplesse pour la gestion de l'espace).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Remarques
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
En effet, je l'oublie tout le temps, parce que je ne l'utilise pas, et je ne l'utilise pas parce que je n'ai jamais vu d'annonce que ce système de fichier était finalisé et officiellement prêt pour la prod. Je ne suis pas du genre à utiliser des FS expérimentaux pour stocker mes données.
[^] # Re: Remarques
Posté par barmic 🦦 . Évalué à 3.
Je fais nettement plus confiance à btrfs qu'à ntfs3g pour le coup. Entre un format qui est maitrisé et dont le développement est assuré directement au sein de la LKML et l'accès à une format géré par divers microsofteries potentiellement avec chacune leurs petites bizarreries hors de la LKML mon choix est vite fais. De la même manière utiliser ext4 sans journalisation qui est un usage non conventionnel du fs et qui va réduire de je ne sais pas sa fiabilité alors qu'une partie de l'outillage s'attend à avoir un journal me paraît tout aussi dangereux.
Je ne suis pas du genre à faire confiance en un élément physique pour stocker mes données (surtout une clef usb ou carte mémoire). Une clef usb c'est la même chose qu'un câble ethernet. Ça permet d'échanger entre 2 machines ou entre 2 OS d'une même machine, mais ça ne va pas plus loin. Pour un disque usb qui servirait de sauvegarde, ça ne se discute pas : fat, exfat et ntfs sont exclus, ils vont te flinguer les droits (je parle bien des droits et pas des propriétaires) et sur disque que ce soit à plateau ou sdd F2FS n'est pas fait pour et je ne vois pas pourquoi désactiver la journalisation dessus.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Remarques
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Oui, moi aussi. Mais ce n'est pas le même usage. Pour échanger des données, ntfs-3g fait partie des choses que j'envisage. Pour le stockage interne de mes ordinateurs, je n'ai jamais considéré l'usage de btrfs.
Si si : https://lwn.net/Articles/518718/
Pour éviter de doubler les écritures, sur des supports dont la durée de vie dépend directement du nombre d'écriture. Il faut aussi être conscient que quand on écrit ne serait-ce qu'un octet, on cause en réalité la remise à zéro d'un bloc d'effacement de l'ordre du mébioctet, et la réécriture des blocs qu'il contenait à des emplacements libres.
[^] # Re: Remarques
Posté par barmic 🦦 . Évalué à 4. Dernière modification le 26 avril 2021 à 12:44.
Même debian le propose sans warning maintenant.
Ils ont revu la journalisation pour qu'elle soit mieux adaptée, mais leur algorithme d'allocation basé sur la géométrie interne ne sert à rien quand tu as un firmware qui est là pour te cacher la géométrie interne et créer une indirection.
Les durées de vies des ssd ont explosées depuis l'époque en question. Si c'était si nécessaire il serait urgent de passer à des fs comme zfs, btrfs ou hammerfs pour supprimer la journalisation sur les disques internes et il serait à propos que les distributions par défaut sur ssd t'installent un fs sans journal donc, mais avec aussi quelques options comme noatime, te mettent un gros warning pour l'usage du swap, etc. Aucune distribution le fait.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Remarques
Posté par Stéphane Ascoët (site web personnel) . Évalué à 0.
Ce qui me pourrit le plus la vie avec la FAT32, c'est le non-support de certains caractères comme ":"
Je voudrais faire un script enveloppant "mv" ayant au moins deux fonctions:
- vérifier que la place libre est suffisante sur la destination avant de commencer;
- Supprimer ce genre de caractères;
Je n'ai jamais le courage de m'y mettre, ayant une idée des gigantesques problèmes qui seront à résoudre, ne serait-ce que la présence d'espaces dans les noms de fichiers, pour n'en citer qu'un. Alors si quelqu'un a déjà fait ça, ça m'interresse au plus haut point! "File Renamer" de Stefan Frost semble faire le second point mais c'est un outil graphique trop lourd à mon goût.
L'UDF pourrait théoriquement convenir pour des cartouches Gigamo, mais je n'ai pas confiance dans ce format qui m'a valu des pertes de données immenses sur CD-RW(avec cette daube de DirectCD). Savez-vous s'il existe un "Undelete" pour UDF? Et un pour vfat avec secteurs de 2 Ko? Je ne comprends d'ailleurs pas pourquoi faire une restauration de fichiers supprimés sur FAT est devenu si compliqué alors que sous M$-DO$, le primitif "UNDELETE" fonctionnait parfaitement.
Ce n'est pas un gage de qualité si Ext2 nécessite un fsck régulier… dans ce cas, l'automatiser avant montage?
J'ai vu BTRFS en standard récemment sur une distribution, je ne sais plus laquelle…
[^] # Re: Remarques
Posté par barmic 🦦 . Évalué à 4.
Quelque soit le système de fichiers j'utilise photorec pour ça.
Tous les fs de MS ont besoin de faire des défragmentation régulières. En soit les fs doivent faire de la correction régulière soit c'est fait offline via un fsck soit une defrag soit en ligne comme le font zfs, btrfs ou hammerfs. Je vois pas où est la question de qualité là dedans.
Si je ne me trompe pas les ext ont un compteur de montages qui indique le nombre de montage sans fsck et indique quand il faut le faire (c'est configurable via tune2fs). C'est fait au démarrage, je n'utilise plus assez ce genre de fs pour savoir si c'est le cas avec des montages manuels.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Remarques
Posté par Stéphane Ascoët (site web personnel) . Évalué à 0.
Oui mais comme tu le dis, ce n'est pas pratique pour les volumes amovibles
# Et vous, quel format utilisez vous?
Posté par xylphute . Évalué à 2.
Perso, je tourne en xfs et une partition partagé entre windows et ma fedora en NTFS. Pour la gestion des droits sur ntfs j'utilise le fichier "UserMapping" avec ntfs-3g.
Pour les clefs USB, ntfs! L'écriture passe bien sûr Linux et je suis sur de passer partout sur les autres machines a l'extérieur de chez moi.
[^] # Re: Et vous, quel format utilisez vous?
Posté par vv222 . Évalué à 3.
ext4 pour tous les supports de stockage internes de mes machines, que ce soit pour les disques durs ou pour les SSD. Souvent sans partitionnement.
UDF pour tous mes supports de stockage amovibles, sans partitionnement.
[^] # Re: Et vous, quel format utilisez vous?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Ext4 pour le stockage interne de mes ordinateurs, mais je pourrais considérer l'usage de F2FS à la place, lorsque c'est sur SSD.
XFS pour un disque dur externe qui me sert à stocker des sauvegardes, l'idée étant de ne pas utiliser le même système de fichiers que la source, au cas où j'aie à faire face à un bug grave de pilote de FS.
F2FS pour le stockage interne de mon téléphone.
FAT32 pour mes clefs USB, ExFAT pour les disques durs externes que je pourrais vouloir prêter à des gens.
# Support
Posté par eingousef . Évalué à 7.
Je n'ai pas suivi l'actualité récente mais mais le dernier écho que j'avais eu sur le sujet, c'était que F2FS présentait un intérêt sur les dispositifs où la mémoire flash était directement accessible par le système (les clefs USB, les cartes flash ou les mémoires internes d'appareils mobiles comme les smartphones), mais pas sur les dispositifs dotés d'un firmware rajoutant une couche d'abstraction entre la mémoire flash et le FS, comme les SSD. En gros les SSD feraient croire au système qu'ils sont des disques durs classiques, et le firmware se charge d'optimiser la lecture et l'écriture du FS sur la mémoire flash. F2FS serait contre-productif dans ce cas-là et il faudrait utiliser un FS traditionnel comme ext4.
Tu as parlé du support sur les *Linux/Windows/MacOS, mais qu'en est-il pour les autres OS ?
Après une petite recherche concernant ext2/3/4 il semblerait que le dénominateur commun soit ext2 (aka ext3 sans journalisation) sur les *BSD. Visiblement FreeBSD et DragonflyBSD peuvent lire ext2/3/4 et écrire sur du ext2/3, sans journalisation. NetBSD et OpenBSD semblent pouvoir lire et écrire ext2/3, mais pas ext4.
Haiku est dans la même situation que NetBSD et OpenBSD. Minix a une page man pour ext2/3/4 donc je suppose qu'il gère les trois. GNU Hurd sait lire et écrire ext2 mais pas ext4 (je ne sais pas quel est le support de ext3).
Les UNIX les plus exotiques (Illumos, Plan9…) sont concentrés sur leurs FS maison (ZFS, 9P…) donc ça m'étonnerait qu'ils sachent utiliser autre chose (mais de toute façon ils sont surtout utilisés dans des environnements où on transfère des fichiers via le réseau).
Pour les clones des OS Microsoft il y a des trucs surprenants : FreeDOS n'a pas de support pour ext2, NTFS ou exFAT mais il a un outil rudimentaire pour copier des fichiers sur et depuis un FS ext2. ReactOS gère FAT32, UDF, Btrfs et ReiserFS, mais ext2 et NTFS ne sont pas encore utilisables.
Et finalement, Rockbox, bien que basé sur Linux, ne gère que le FAT32.
Il faut aussi noter que le cas de figure mentionné ici, c'est celui d'un dispositif de stockage formaté directement. Si on rajoute une couche de sous-partitionnement (comme LVM) ou du chiffrement (LUKS, GELI), ça se complique. Même le simple choix de la table de partition (msdos ou GPT) peut être un problème : rockbox par exemple ne gère pas GPT.
Avec rockbox il peut y avoir d'autres cafouillages : par exemple si par mégarde j'ai créé une partition FAT32 sur ma carte au lieu de la formater directement, rockbox ne pourra pas la reconnaître à l'insertion et devra rebooter pour pouvoir la lire.
Enfin tant qu'on en est à parler d'ordinateurs qui lisent des données depuis un disque amovible, c'est dommage de faire l'impasse sur tous les ordinateurs disposant d'un kernel maison sur lequel on n'a généralement zéro contrôle : baladeurs, appareil photos, téléphones mobiles, imprimantes…
Typiquement mon APN prend des cartes SD jusqu'à 32GB et SDXC au-delà de 32GB. Il peut lire une SD de 32GB formatée en FAT32 mais refuse de lire une SDXC de 64GB si elle n'est pas formatée en exFAT. Et j'ai toujours eu des problèmes pour utiliser exFAT sous Linux (pourtant je suis en 5.10) :
udevilne veut pas monter la carte, je suis obligé d'utilisermount, et une fois la carte montée tout est enroot:rootet je ne peux pas changer les permissions des fichiers déjà existants (chownrenvoie une erreur etchmodéchoue silencieusement).*splash!*
[^] # Re: Support & performances
Posté par Xanatos . Évalué à 2.
Je rejoins sur certains problèmes comme GPT et exFAT.
J'ai arrêté de mettre GPT en table de partition, on m'envoi souvent balader.
Exfat pourrait être bien, si et seulement si les Windows acceptaient les clés formatés en exfat depuis ma Debian, j'ai pas encore saisi ou ça coince, assez aléatoire.
Mais surtout la catastrophe en écriture avec le driver ntfs-3G, comme si on atteignait le maximum d'un tampon quelque part. Je m'étais amusé à faire bench d'un disque dur sur 2 OS avec différents formatages et transferts différents chunks, c'est sans appel, ntfs-3G ne décolle pas.
Merci pour F2FS et UDF, je ne pensais pas utilisable sur des clés.
[^] # Re: Support
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Les clefs USB et autres mémoires flash ont une couche d'abstraction, même si elle est peut-être plus rudimentaire. Sans couche d'abstraction, une mémoire flash se comporte d'une façon trop différente d'un périphérique bloc normal : elle est constituée de blocs qu'on peut écrire, mais pas modifier ensuite, et de blocs d'effacement, qui regroupent plusieurs blocs, qu'on peut effacer ensemble.
[^] # Re: Support
Posté par yinqi . Évalué à 0.
Je préfère distinguer les besoins suivants et choisir ensuite le format en fonction :
Faire les sauvegardes sur un support formaté dans un format identique à celui des fichiers sauvegardés, si possible dans le format le mieux pris en charge possible par le SE qui fait la sauvegarde.
Pour faciliter les échanges, par défaut utiliser exFAT. exFAT a de très nombreux avantages sur FAT32, comme la taille de fichier, la fiabilité, les performances, et tous les équipements modernes l'utilisent en général pour SDCard rapides.
Pour les besoins spécifiques, ajuster selon le cas, toujours en privilégiant exFAT chaque fois que possible. Par exemple une USBKey à mettre sur Autoradio => FAT32 si l'autoradio ne lit rien d'autre, mais essayer exFAT d'abord.
Enfin, pour limiter les problèmes, formater le plus possible sous le SE le plus naturel pour le format : Formater en NTFS, FAT32, exFAT sous Windows, même si ça marche sous Linux par exemple, et même le support est ensuite uniquement utilisé sous Linux.
# Concernant le ID-mapping
Posté par Vincent-Xavier JUMEL (site web personnel) . Évalué à 4. Dernière modification le 26 avril 2021 à 00:40.
Je viens de voir passer https://lwn.net/Articles/837566/ qui permet de résoudre des cas de mappings d'ID.
# ZFS ?
Posté par Yggdras . Évalué à 2.
OpenZFS a l'air de supporter de base Linux, et il existe des ports pour MacOS et Windows. Est-ce que ça serait une autre piste possible pour partager des fichiers ?
Avoir à installer un driver ne me parait pas rédhibitoire, tant que ça permet d'accéder aux fichiers. Et ZFS a plein d'avantages, comme l'encryption ou la compression.
# Je veux pas dire, mais Windows lit tous les FS :)
Posté par pasBill pasGates . Évalué à 5. Dernière modification le 25 mai 2021 à 20:09.
https://docs.microsoft.com/en-us/windows/wsl/wsl2-mount-disk
[^] # Re: Je veux pas dire, mais Windows lit tous les FS :)
Posté par Psychofox (Mastodon) . Évalué à 8.
Purée ce que c'est pas près pour le desktop ce windows, faut se taper plein de ligne de commande pour monter un simple disque.
[^] # Re: Je veux pas dire, mais Windows lit tous les FS :)
Posté par pasBill pasGates . Évalué à 4.
C'est la faute a Linux, comme d'hab :)
[^] # Re: Je veux pas dire, mais Windows lit tous les FS :)
Posté par Psychofox (Mastodon) . Évalué à 5.
j'ai pas besoin de ligne de commande pour les monter depuis gnome3 :)
Bon apparemment on peut aussi utiliser des applis graphiques dans wsl2 sur les dernières builds (y compris du wayland apparemment) donc j'imagine que ça doit être possible de monter directement depuis nautilus ou dolphin :
https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-apps
https://devblogs.microsoft.com/commandline/the-initial-preview-of-gui-app-support-is-now-available-for-the-windows-subsystem-for-linux-2/
[^] # Re: Je veux pas dire, mais Windows lit tous les FS :)
Posté par Stéphane Ascoët (site web personnel) . Évalué à -1.
Et surtout, leurs lignes de commandes sont toujours aussi pénibles, à des milliards d'années de la concision de celles des OSes Posix
[^] # Re: Je veux pas dire, mais Windows lit tous les FS :)
Posté par pasBill pasGates . Évalué à -1.
LOL
Reviens nous en parler une fois que tu auras essayé de passer des données structurées entre 2 commandes.
Les shells Unix c'est la préhistoire, leur seul avantage est qu'ils existent depuis longtemps et les gens y sont habitués. Le monde moderne c'est les shells type Powershell (qui est dispo sur Linux d'ailleurs)
[^] # Re: Je veux pas dire, mais Windows lit tous les FS :)
Posté par jyes . Évalué à 5.
J’ai regardé par curiosité, et c’est quand-même limité (pour le moment ?) :
[^] # Re: Je veux pas dire, mais Windows lit tous les FS :)
Posté par claudex . Évalué à 9.
Du coup, je découvre qu'il y a une différence entre les USB flash drives et les USB disks, je pensais que c'était vu de la même façon depuis l'OS.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# en même temps...
Posté par fearan . Évalué à 4.
l'intérêt de la gestion des droits (autre que exécution) sur un périphérique externe me laisse dubitatif. Je peux très bien le brancher sur un pc perso avec le login d'un autre, ou en tant qu'administrateur et paf!
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# exFAT et UDF
Posté par harlock974 . Évalué à 6.
La commande ne marche pas. Sur Linux Mint c'est, sous root ou sudo :
mkfs.exfat -n "Clef Cyrano" /dev/sdcPour UDF c'est :
mkudffs --media-type=hd -l "Clef Cyrano" --blocksize=512 /dev/sdcSi l'on ne précise pas
blocksizela clé n'est pas lue sous Windows (mais ça marche sous Linux).Habituellement je formate mes clés et disques USB avec UDF, mais récemment un ordi Windows 10 a refusé d'en lire un. J'essaierais avec exFAT maintenant que les spécifications sont ouvertes.
[^] # Re: exFAT et UDF
Posté par Donk . Évalué à 6.
À cause de l'espace manquant?
[^] # Re: exFAT et UDF
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Corrigé, merci.
[^] # Re: exFAT et UDF
Posté par Frédéric Blanc . Évalué à 4.
Il va falloir ressortir la gomme et le crayon : la bonne option de mkfs.exfat pour définir le nom du volume, c'est -n et non -L.
[^] # Re: exFAT et UDF
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
https://man.archlinux.org/man/mkfs.exfat.8
mkfs.exfat [ -b boundary_alignment ] [ -c cluster_size ] [ -f ] [ -h ] [ -L volume_label ] [ --pack-bitmap ] [ -v ] device
mkfs.exfat -V
https://manpages.debian.org/wheezy/exfat-utils/mkfs.exfat.8.en.html
[^] # Re: exFAT et UDF
Posté par Frédéric Blanc . Évalué à 4.
OK, logique qu'Archlinux et Debian (ou autres) ne soient pas d'accord sur les options : leurs paquets sont issus de deux sources différentes.
* Archlinux (et autres -n-istes) : https://github.com/exfatprogs/exfatprogs
* Debian (et autres -L-istes) : https://github.com/relan/exfat
Il semblerait que Debian propose aussi les exfatprogs dans SID : https://packages.debian.org/sid/exfatprogs
[^] # Re: exFAT et UDF
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 28 mai 2021 à 22:17.
J'ai déjà vu les deux… l'un pour Name et l'autre Label et me demande quelle est la différence (il semble que l'un est au niveau partoche même et l'autre dans le système de fichiers…) On peut aussi passer par un autre outil qui ne formate pas : fatlabel (dosfstools) ou mlabel (mtools) par exemple.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.