Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Windows 11 : Microsoft abolit la limitation de 32 Go en FAT32, sous conditions

Le 19 août à 10h19

Comme nous l’avions expliqué dans notre dossier sur les systèmes de fichiers, la FAT32 est arrivée en 1996, après la FAT16. Pour les amateurs d’archéologie, on rappellera que la FAT16 était maitre des lieux au lancement de Windows 95. Il faudra attendre la version OSR2 (OEM Service Release 2) pour que la FAT32 débarque.

Du FAT32 à 2 To pour les Insider sous Windows 11

La FAT32 propose pour rappel un codage sur 28 bits, avec une taille maximale de 4 Go pour les fichiers et de 2 To pour les partitions. Mais un point important est à préciser : les outils intégrés de Microsoft ne dépassaient pas 32 Go. Des logiciels tiers permettaient par contre de s’affranchir de cette limite arbitraire.

Près de 30 ans après la sortie de la FAT32, Microsoft dépasse enfin cette limite arbitraire de 32 Go dans Windows 11. Il faut pour cela être dans le canal Insider, disposer de la Preview Build 27686 (qui propose d’autres nouveautés) et utiliser la ligne de commande.

« Lors du formatage de disques à partir de la ligne de commande à l'aide de la commande "format", nous avons augmenté la limite de taille FAT32 de 32 Go à 2 To », soit le maximum permis par le système de fichiers. Et ça marche, comme l’indique Xeno sur X.

Pour le moment, seule la ligne de commande est concernée, pas (encore ?) la boite de dialogue qui commence à bien accuser son âge. Cette fonctionnalité est sur le canal Insider et ne sera pas obligatoirement déployée sur les versions finales, affaire à suivre.

Une boite de dialogue temporaire… pendant 30 ans

En mars de cette année, Dave Plummer, ancien de chez Microsoft, est revenu sur cette fameuse interface graphique pour formater un périphérique de stockage. Elle a été écrite « un jeudi matin pluvieux chez Microsoft, fin 1994 », se souvient-il.

« Nous étions en train de porter les milliards de lignes de code de l'interface utilisateur de Windows 95 vers NT, et Format était l'un des domaines dans lesquels Windows NT était suffisamment différent de Windows 95 pour que nous ayons à créer une interface utilisateur personnalisée ».

Un passage par Visual C++ 2.0 plus tard, une première version était développée. « C'était il y a environ 30 ans, et la boite de dialogue est toujours ma version temporaire de ce jeudi matin, alors soyez prudent lorsque vous faites des solutions "temporaires" », s’amuse-t-il.

Il en profite pour rappeler que la limite des 32 Go était « un choix arbitraire ce matin-là, qui est resté comme un effet secondaire permanent. Alors, rappelez-vous… il n'y a pas de versions "temporaires" :) ».

Le 19 août à 10h19

Commentaires (48)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar
Ça doit être un sacré challenge pour retrouver le code source de cette interface ....😅
votre avatar
M'est avis qu'à ce niveau, autant tout réécrire de zéro, non ?
votre avatar
Pas forcément. Le code source n'a probablement jamais fini dans un tiroir, le code des différents composant inclus dans Windows devant être recompilable, au minimum, pour permettre de supporter les nouvelles plateformes.
Par contre il est possible qu'en terme de qualité du code, ça ne soit pas aux standards actuel et que Microsoft trouve que ça soit une bonne occasion et le refaire avec les API Windows modernes.
votre avatar
Bof, pas forcément. D'autant que des formats ont été ajoutés depuis (exFAT notamment au milieu des 2000's et peut-être ReFS plus récemment ?).
votre avatar
Du temporaire qui dure, rien de plus classique. Mais bon tant que ça fait le job pas de raison de toucher un truc qui marche.
votre avatar
Et, quand Windows ne connait pas un système de fichiers tiers (par exemple car on a un double boot), quand est-ce que cet OS totalement crétin va arrêter de vous proposer la fameuse boite de dialogue temporaire-qui-dure afin de formater cette partition?

Idem quand un stockage est crouillé au point de ne même plus identifier le système de fichier: Combien de personnes, même sans double boot, on-t'elles ainsi hypothéqué encore un peu plus les possibilités de récupération de leurs données (idéalement non sauvegardées) à cause de ce comportement incroyablement stupide?
votre avatar
J’ai un disque dur externe USB de 2 Tio formaté d’usine en NTFS (GPT). Depuis au moins Noël dernier, Windows refuse de le voir autrement qu’en RAW et ne propose que de le formater si je le lui connecte (testé sur trois ordis différents avec différentes versions de Windows).
Pourtant, ce disque est parfaitement utilisable sous Linux (via le pilote NTFS-3G) et je peux tout à fait lire et manipuler des fichiers sur ce disque. Je peux même les copier sur une clef USB depuis Linux et les faire lire ensuite par Windows.

Si quelqu’un sait comment faire pour que Windows reconnaisse à nouveau ce disque, sans que ça n’oblige à le formater (je veux pas que ça touche aux fichiers déjà présents dessus), je prends.
votre avatar
J'ai déjà eu un cas similaire il y a des années. Le problème était le type de partition renseigné au niveau de la table des partitions (bon, c'était du MBR à l'époque, mais le principe doit rester le même sur GPT).

Le type de partition ne signifie pas le formatage de la partition. Mais un mauvais type peut empêcher Windows de reconnaitre la partition. Si c'est ça, la chance, c'est que c'est facilement changeable.

Je t'invite à regarder sous Linux le type de la partition (via fdisk par exemple), et voir si cela correspond à ce qu'attends Windows, et pas un truc "farfelu" genre "linux swap".
votre avatar
Un linux-swap c'est du raw non formaté et ce serait parfaitement normal. Attention car en GPT si la table de partition normale est crouillée Linux est peut-être capable d'utiliser sa sauvegarde (ce qui n’existait pas en MBR) en fin de "disque" tandis que windows pourrait rester coincé comme un c.. sur celle au début...
votre avatar
Tu confonds 2 choses : le type de partition, et son formatage. En théorie, les deux doivent être cohérents.

Quand tu as une partition swap, on s'attend effectivement à ce qu'elle soit utilisée pour du swap. Mais rien n'empêche d'avoir une partition marqué comme swap, mais d'y mettre un système de fichier et de monter ensuite la partition (bon, j'ai pas tenté dernièrement cette opération, mais j'ai déjà utilisé cette astuce par le passé).

C'est un peu le même principe que pour les extension de fichier si tu veux. On s'attend d'un .txt de contenir du texte et un .exe d'être un exécutable pour Windows. Mais rien n'empêche d'avoir un .exe qui contienne du texte et un .txt du binaire. Mais si tu essayes d'ouvrir un .exe qui contient du texte, tu ne vas pas avoir notepad qui s'ouvre, mais un message d'erreur t'indiquant que l'exécutable n'est pas valide.

En refouillant un peu, le problème que j'avais eu, c'était une partition du "mauvais type". J'avais formaté un disque en NTFS depuis Linux. Aucun problème sous Linux, mais impossible d'accéder au disque sous Windows. En cause, le type de partition qui était 0x86 au lieu de 0x87 (ou inversement, je ne sais plus l'ordre). Les deux étaient marquées comme étant des partitions "NTFS". C'est en faisant des tests et en comparant les partitions formatés sous Linux et sous Windows que je me suis rendu compte de ça. C'est con, j'ai mis un moment avant de trouver, mais après ça a marché sans aucun problème.
Attention car en GPT si la table de partition normale est crouillée Linux est peut-être capable d'utiliser sa sauvegarde
A moins d'éditer à la mano directement avec un éditeur hexadécimal le GPT directement sur disque, je pense qu'il y a peu de risque de flinguer sa partition GPT ou sa sauvegarde en utilisant des outils comme fdisk. Faire des conneries oui, bousiller complètement sa GPT, peu de chance.
votre avatar
J'ai déjà vu de la table de partition flinguée sur un bug du firmware du stockage qui causait des corruptions de la taille d'une page (8k sur ce modèle de ssd) sur reboot. Paradoxalement le cas power-off-on était mieux géré.
Donc ca arrive mais c'est rare et forcément toujours hautement suspicieux.
Sinon windows qui ne va pas voir direct dans la partition mais utilise une info redondante voir source d'erreur comme ton cas l'illustre c'est pas malin. Pas besoin de lire des étiquettes sur les étagères quand on peut voir comment c'est organisé dessus. Surtout que partitionnement et formatage sont le fait d'outils disjoints et que ce type de dépendance ne peut apporter que des ennuis. On peut avoir partitionné ily a 10 ans et reformater avec un FS qui n'existait alors pas depuis...
votre avatar
Franchement, les discours le choix de Windows est nul, Linux c'est mieux, sans mieux comprendre les tenants et aboutissants, c'est fatiguant.

Oui, Windows et Linux ne traitent pas de la même manière beaucoup de chose. Ce n'est pas parce que c'est différent que l'un est mieux que l'autre.

Historiquement, Windows a toujours monté les partitions par défaut, sans action de l'utilisateur, contrairement à Linux, où il fallait se farcir le /etc/fstab. Du coup, linux n'avait pas besoin de se fier au type de partition, car c'est l'utilisateur (administrateur du système) qui lui donnait la marche à suivre.

Aujourd'hui, le type de partition est encore utilisé, indépendamment du FS, et Linux le fait aussi maintenant (enfin les automounter), pour éviter de monter automatiquement les partitions qui n'ont pas à l'être (partition de recovery par exemple).
J'ai déjà vu de la table de partition flinguée sur un bug du firmware du stockage qui causait des corruptions de la taille d'une page (8k sur ce modèle de ssd) sur reboot
Donc c'est le DD qui est défaillant, pas les outils ;)
votre avatar
Je ne dis pas que c'est nul, juste qu'il est de manière générale préférable d'éviter ce type de doublon qui ne peut n’amener que des emmerdes en créant des dépendances dont on sait se passer:
-Cycles de MAJ des outils de partitionnement/formatage qui peuvent poser pb avec l'évolution des FS supportés. Pire encore quand 2 OS différents se partagent une même machine.
-Se retrouver à toucher des tables de partition hors partitionnement initial, sur un formatage: Risque de planter tout le stockage (et rendre la machine impossible à booter) si pb lors de l'écriture ou coupure alim qui tombe mal... Ici, pas besoin d'un firmware de stockage buggé pour arriver d'un chemin différent au cas évoqué. Bref, une table de partition on l'écrit une fois puis on ne fait que la lire, toute approche différente c'est des risques évitables.
-Si je monte de l'ext4 manuellement, pas besoin de le spécifier au mount il reconnait et s'en démerde sous Linux, sauf s'il y a un pb (raison sans doute de la mention du type de FS dans le fstab) et je trouve plus sûr d'avoir le type de FS dans un fichier texte qu'une table de partition (on bénéficie en prime de la journalisation pour éviter une machine un-bootable si on ne touche pas à la partition de boot), puis au moins on est certain de la cohérence de vue d'un même OS avec lui-même (tandis qu'une table de partition peut être faite par l'un puis utilisée par l'autre).
votre avatar
Bref, une table de partition on l'écrit une fois puis on ne fait que la lire, toute approche différente c'est des risques évitables.
ça, on est d'accord.

Maintenant attention (car je pense que c'est de là que vient la méprise) : ce n'est pas parce que Windows tient compte du type de partition que celle-ci doit changer à chaque formatage. C'est seulement si le type de partition est inadéquat (=pas approprié au stockage de données) ta partition ne sera pas reconnue par Windows. Ca ne va pas plus loin que ça. Mais ça ne veut pas dire qu'à chaque formatage ou changement de FS, tu changes le type de partition.
je trouve plus sûr d'avoir le type de FS dans un fichier texte qu'une table de partition
Problème de l'oeuf et de la poule ;) Pour avoir les FS, il te faut monter un FS.

Je me demande aussi si le problème initial ne pourrait pas être lié aux SMART. Ca ne m'étonnerait pas que Windows ne monte pas automatiquement un disque qui présenterait des anomalies, afin de protéger les données.
votre avatar
Si on ne modifie pas côté partitionnement on risque de se retrouver dans ton cas vécu avec une ex partition swap convertie en stockage qui ne sera pas exploitable d'un OS qui se base avant tout sur les infos de la table de partition. AMHA, le mieux est encore que le dangereux couteau qui sert à couper le gâteau reste bien séparé de la cuiller servant à le manger.

Le pb d'oeuf et de poule ne se pose que pour la partition racine... qui si elle a un pb au point de ne même plus savoir identifier le FS avec ses magic number et autres métadonnées ne risque pas d'être vue bootable par le boot-loader, qui a en prime toutes chances d'implementer un simple reader très incomplet vs le support FS complet sous OS (j'ai vu u-boot sur de l'embarqué incapable de rejouer un journal Ext4 sur coupure d'alim: Si cela tombait sur un fichier utile au boot, même une simple config dont la version antérieure n'aurait pas posé de pb, tu étais coincé mais extraire le stockage et le monter sur un PC Linux corrigeait le pb derrière ton dos sans action utilisateur. C'était un rollback sur la partition/version passive ; Idem avec des UEFI intégrant un driver Ext4, de ce côté les inodes 64bit devenues le défaut sur une nouvelle version de mkfs il y a 6 ou 7 ans lui posaient soudain pb sans rien avoir changé aux outils/options utilisées pour créer les médias de boot).

Le côté SMART n'est pas intégré direct au montage, trop spécifique (stockages USB, image montée via un device loop...). Un montage ou re-montage read-only en cas de pb c'est courant mais c'est l'OS qui gère. Parfois c'est même le controleur du stockage qui le passe RO au niveau du matériel (systématique sur les SSD).
votre avatar
Si on ne modifie pas côté partitionnement on risque de se retrouver dans ton cas vécu avec une ex partition swap convertie en stockage qui ne sera pas exploitable d'un OS qui se base avant tout sur les infos de la table de partition
Ce n'était pas un changement permanent, juste temporaire le temps de pouvoir résoudre des problèmes, et où j'avais besoin d'un espace de stockage temporaire le temps de réaliser mon opération (et sans possibilité de connecter une clé usb ou autre, sinon, c'est pas drole).
Le pb d'oeuf et de poule ne se pose que pour la partition racine...
Ben oui, mais il se pose. Et plutôt que d'avoir plusieurs mécanismes en place, autent en avoir le minimum. Et le système de partition est obligatoire en plus d'être indépendant de l'OS ;)

Après, que les bootloader n'ait qu'un support complet, ça ne m'étonne pas. Et dans un sens, tant mieux. Ils n'ont besoin que d'un accès en lecture, et ce n'est pas le rôle d'un bootloader de "réparer" les défaillances d'un FS.
Le côté SMART n'est pas intégré direct au montage, trop spécifique
Détrompe toi. Certains BIOS/UEFI désactive purement et simplement l'accès au disque si le rapport SMART n'est pas bon. C'est vrai pour les disques internes (SATA, nvme, ...). Mais je ne pense pas que cela soit le cas pour les disques USB (le blocage par le BIOS j'entends)

Par contre, cela ne m'étonnerait pas du tout que Windows empêche le montage d'un disque dont le rapport est mauvais. Enfin juste mauvais non, car j'ai déjà pu monter des disques USB présentant quelques défaillances sous Windows, mais les défaillances critiques peuvent peut-être être bloquantes (et c'est en écrivant ce commentaire que je me rends compte d'une explication plausible à un disque USB que je ne peux plus utiliser sous Windows).
votre avatar
"Ben oui, mais il se pose."

Je n'ai pas vraiment dit le contraire, mais souligné que cette mention du fstab n'est potentiellement utile que pour un FS cassé au point qu'un mount ne saurait plus l'identifier automatiquement.

Et que rendu là, une partition racine (ou le fstab est logé) aurait toutes chances d'être bien trop mal en point pour être bootable, même en lisant le type de FS en table (sans pb théorique de poule/oeuf)!

Bref, les cas où lire l'info en table serait en pratique salvateur ça doit pas faire bézef. En tout cas AMHA loin de compenser les risques évoqués si l'on veut tenir cela à jour (ou pas) en cas de changement de FS.
votre avatar
Le disque était formaté d’usine. Le seul truc que j’ai fait dessus a été de le brancher une première fois sous Windows (là, il le reconnaissait !), changer le nom du volume et peut-être demander à DiskPart de le mettre en lecture seule (attribut NTFS géré uniquement par Windows, Linux peut toujours écrire dessus). J’ai jamais reformaté ni employé d’outils touchant au partitionnement depuis Linux (je fais jamais ça avec des FS Microsoft). Après, j’ai fait que le remplir depuis Linux, sans le moindre problème depuis janvier 2023. Je vois pas pourquoi le type de FS de ce disque aurait magiquement changé dans l’intervalle, surtout en n’ayant jamais fait autre chose que de la bête copie de fichiers dessus.

Ce n’est qu’un an plus tard, quand j’ai voulu copier l’ISO de Windows 11 23H2 que j’avais mise dessus sur le PC qu’on m’a offert à Noël, que j’ai découvert que Windows ne reconnaissait plus le FS du disque. Et ce, sur les deux machines Windows que j’ai chez moi, de même que le PC portable dont ma tante a hérité.
votre avatar
Clairement, le type d'une partition ne change pas tout seul. Donc si ça fonctionnait avant, peu de chance que ce soit ça.

As tu essayé de faire une vérification manuelle du disque sous Windows, avec CHKDSK par exemple ? Car tu as fais un truc que je trouve funky et qui pourrait causer ce problème : tu as passé ton système de fichiers en lecture seule, mais tu as continué d'écrire dessus sous Linux. S'il y a des checksums de positionné au moment où le disque est passé en lecture seul, mais pas mis à jour depuis (car modif faite depuis linux), cela pourrait expliquer que Windows voit le système de fichier comme corrompu et t'invite donc à le formater.

De même, ntfs-3 reste limité sur certains aspects, comme la journalisation (ce qui pourrait aussi expliquer le comportement que tu observes)

[edit]
ou virer l'attribut read-only s'il est présent. Car que peut faire Windows si le système de fichier est corrompue, mais que la partition est marquée comme readonly ? Impossible de la réparer => formatage.
votre avatar
Je sais pas si Dave Plummer a la mémoire qui commence à lui faire défaut (c’était bien arrivé à Raymond Chen à propos de la raison pour laquelle Pinball 3D avait été retiré de Windows Vista : il avait confondu les versions IA64 pour processeurs Itanium avec les x86-64), mais Wikipédia affirme que cette limitation de 32 Gio pour les volumes FAT32 n’existe que depuis Windows 2000 et n’a concerné que la famille Windows NT capable de prendre en charge FAT32 nativement (2000, XP, Vista, etc.), les Windows 9x n’ayant pas été affectés par cette limitation. Du reste, les outils de partitionnement tiers n’ont jamais été limités de leur côté.

Ça ne ferait donc que 25 ans (Windows 2000 est sorti en 1999) que cette limitation artificielle existe, et nombreux sont ceux qui pensent qu’elle n’était motivée que par le désir de Microsoft de pousser à l’usage de NTFS à la place de FAT32, surtout en tant que volume système.
votre avatar
Peut-être, mais du temps de win95 et antérieurs un HDD c'était quelques (petites) centaines de Mo (et côté RAM, qq Mo). Le besoin de dépasser 32Go ne concernait donc pas le PC et l'affaire ne risquait pas d'être tentée. Ces besoins, c'était au rayon stations de travail Unix d'alors, avant que l'évolution des PC combinée à Linux ne tue ce marché (et des SGI et autres Sun Microsystems)... et on ne risquait pas de voir ces systèmes utiliser un FS ne sachant pas gérer des droits utilisateur!

Le 1er PC que j'ai eu à moi (un 486DX33), en 1993, c'était 130Mo de HDD et 4Mo de RAM: Ça permettait déjà de jouer à DOOM.
votre avatar
Quand Windows XP est sorti fin 2001, les disques durs avaient déjà atteint les 40 Gio, et beaucoup d’utilisateurs sont restés sur Windows 98 au moins jusqu’en 2004 et la sortie d’XP SP2. Eux ont pu vérifier si Windows 98 (qui ne prenait pas NTFS en charge, à part via un lecteur réseau) acceptait nativement de formater au-delà de 32 Gio, puisque cette capacité était déjà dépassée à cette époque (on était déjà au moins à 320 Gio en 2004, non ?).
votre avatar
Utiliser fat32 sur un disque de 320gio, ça fait que le moindre fichier créé pèse 5Mo (320 000/ 65000 entrées possibles) non?
C'était une bonne pratique de passer à NTFS de toutes façons, sauf à manipuler de gros fichier et de se moquer de tout perdre pour un petit bug...
votre avatar
« Utiliser fat32 sur un disque de 320gio, ça fait que le moindre fichier créé pèse 5Mo (320 000/ 65000 entrées possibles) non? »

Non : c’était toujours 32 kio par cluster, donc 32 kio minimum par fichier (là où NTFS reste par défaut à 4 kio).

Mais là n’était pas la question, de toute manière : je venais pas discuter de l’intérêt de NTFS sur FAT32 (personne ne le discutera, tellement il est évident ; FAT32 n’ayant pour lui que le fait d’être reconnu par tout le monde à la différence de NTFS, même aujourd’hui sur des télés, consoles de jeu ou lecteurs Blu-ray de salon), mais du fait que la limite à 32 Gio sur les volumes FAT32 n’existait pas, même chez MS, avant la sortie de Windows 2000 (les Windows NT précédents ne sont pas concernés car ils ne prenaient pas FAT32 en charge, pas même Windows NT 4.0 avant qu’on lui ajoute le SP4 ou 6, je crois). Et que d’aucuns y ont vu une manœuvre – dont l’entreprise est passée maître du genre au cours de son histoire, surtout sous l’ère Gates – pour forcer la main aux utilisateurs pour migrer vers NTFS, alors qu’ils auraient préféré rester en FAT32 (pour des raisons diverses, comme celle de l’universalité en cas de dual boot avec un Linux, par exemple).

Si Dave Plummer dément cette intention, très bien, mais il le fait bien (25 ans !) trop tard, car cette hypothèse a bien eu le temps de s’ancrer dans les esprits et de devenir « la » vérité pour l’opinion, et elle ne va pas en être éjectée en un claquement de doigts…
votre avatar
Pardon, les 65000 fichiers, c'était la fat16. Par contre les clusters peuvent être de 4 à 64ko, au choix (et selon la taille de la partition, le 4k peut être indisponible, car la limite est de 250M d'entrées, avec 4ko on couvre 1to maxi)

De toutes façons, la limite à 4go des fichiers, le manque de sécu et de métadonnées ont tué la fat32 pour les jeux et les films et les os.
votre avatar
De mémoire
La limitation n'était que pour le programme de formatage sous 2000 et suivant , et uniquement pour le format natif , la prise en charge de plus de 32gig était sans problême car pas limitée
( par exemple avec un utilitaire comme fat32format )
votre avatar
Ça parle du portage en 94 vers Windows NT, donc code différent de win9x (95,98 et ME). A vérifier sur NT 3.5 sorti la même année.
Windows NT c'est NTFS pour raisons qu'il y a besoin des droits ACL pour le système lui-même, pour des raisons évidentes de sécurités.
votre avatar
Comme je viens de dire dans le message que je viens de poster (le #4.6) : cette vérification est inutile, et pour trois raisons :

* FAT32 n’est apparu qu’en 1996 et, s’il paraît que Windows 95 OSR 2 fut le premier à le prendre en charge, je me rappelle n’en avoir entendu parler que lors de la sortie de Windows 98 deux ans plus tard, où ce FS était annoncé en grandes pompes parmi les nouveautés majeures, avec Windows Update et Active Desktop.
* Côté Windows NT (qui était conçu par une équipe différente de celle des Windows basés sur MS-DOS, y compris la série Windows 9x/ME), il aura fallu attendre Windows 2000 pour que FAT32 soit intégré nativement. Ni Windows NT 4.0, ni encore moins les précédents, ne le prenaient en charge (il fallait installer un Service Pack pour que WinNT 4.0 reconnaisse enfin ce FS, peut-être le SP4 ou le 6).
* Windows NT 3.5 était encore basé sur l’UI de Windows 3.1, donc sa boîte de dialogue de formatage était organisée tout à fait différemment.
votre avatar
Dans un précédent job, j’avais acheté un logiciel (une librairie en fait) à une entreprise. Le soft était très buggé, et paraissait être en béta. J’ai appris quelques années après que dans cette boite les développeurs mettaient les preuves de concept dans une dossier partagé et que les commerciaux avaient accès à ce dossier. Il arrivait parfois qu’ils vendent directement le soft sans en informer les devs. Le client se retrouvait donc avec une preuve de concept très buggée.
votre avatar
ça m’étonnerai pas que ça soit aussi un peu la faute du client
- Faites moi un POC
- Le voila
- Trés bien, ça correspond à ce que je veux. mettez le en production
votre avatar
Désormais, dans les boites aux process-boulets cons comme la lune au point de tout bloquer, faire un "démonstrateur" permet de bypasser le foutoir et une fois que les commerciaux l'ont vu fonctionner, ils demandent à pouvoir le vendre!
votre avatar
Ordres du Docteur : je dois diminuer les calories ("léger" surpoids, hem, toussa, voilà voilà...), donc le FAT, j'essaie d'éviter...
votre avatar
Le gras, c'est la vie.
votre avatar
Je ne comprends pas de quel(s) intérêt(s) FAT32 dispose(nt) par rapport à d'autres formats existants.

Si on restreint la réflexion aux formats voulus par M$ (les siens propres, donc), de souvenir, il me semblait que justement NTFS (v1 puis v2 si je me souviens là aussi bien) venait compenser FAT32, notamment au niveau des descripteurs de sécurité.
votre avatar
L’universalité de la prise en charge, comme je l’ai dit dans le message #4.6 : FAT32 est lu et modifiable par absolument tout ce qui existe et peut lire des fichiers, ce qui n’est pas le cas de NTFS qui, quand il est pris en charge (demande à ta télé ou ta console de jeux, surtout si elles datent des années 2010 et avant : la clef USB ou la carte SD formatée en NTFS, elles n’en voudront pas ; alors qu’en FAT32, aucun problème !), ne l’est souvent qu’en lecture seule sur les systèmes non-MS (à commencer par macOS).

De plus, les partitions EFI des systèmes récents en UEFI sont formatées en FAT32, pas en NTFS. Seule la partition contenant le dossier Windows l’est. Même avec Linux en mono boot, cette partition EFI est en FAT32 et pas en Ext4, Btrfs ou XFS.
votre avatar
Le successeur de fat32, c’est exfat. Globalement, tout système de fichier avec des fonctions de sécurité, sur un périphérique nomade tel qu’une clé usb ou un disque dur externe, ça ne fonctionne pas : les info de propriétaires / groupes sont stockées sous forme d’uid numériques, et ceux-ci sont variables d’une machine à l’autre -> on se retrouve rapidement avec des problèmes de droit.
votre avatar
1. Je veux bien, mais en dehors des PC, ExFAT est pris en charge par quoi ? Les appareils photo numériques, au mieux ? Pour autant que je sache, toutes les cartes SD/µ-SD et les clefs USB vendues dans le commerce sont toujours préformatées en FAT32 et rien d’autre (et à part toi, peut-être, qui va reformater direct les supports achetés en ExFAT ?). Que ce soit pour une bonne ou une mauvaise raison, ça, c’est une autre histoire, mais ça reste un constat de l’inertie de l’industrie dans ce domaine.

2. Va dire ça aux fabricants de disques durs externes qui préformatent leurs produits en NTFS… Là aussi, qui va reformater après dans un autre FS, à part des gens qui n’ont que du Linux ou de l’Apple chez eux et qui auront envie de les passer en Ext4 ou autre pour Linux, ou en APFS pour macOS (mais ça implique que ces disques ne sortiront pas de chez eux ou ne seront jamais branchés sur autre chose que du Linux/macOS) ?
votre avatar
Les cartes sd > 32go ne sont pas en fat 32 mais en exfat.
votre avatar
Et on ne le dit pas assez, mais FAT/ ExFAT, en plus d'être reconnu par quasi-toutes les distris Linux + macOS, est plus rapide que NTFS / EXT4 / HFS / APFS / toussketuveuh !
Naquenaquenaireuh... Bleblebelebeleuh... Vi je retourne en maternelle... :win: :bisous: :langue:
votre avatar
Ça sort d'où cette historie de performance ?
En performance brute sur un système de fichier fraichement mis en place, c'est le périphérique qui est testé.
Sur un système de fichier qui a vécu, il faut penser à la fragmentation, et FAT ne prévoit juste… rien. Ça sent la douille, non ?

Et puis en conditions réelles, avec mix de petits & gros fichiers, ça m'étonnerait bien que les travaux sur ext aient obtenu moins bien que l'absence des mêmes travaux sur FAT (qui a les mêmes spécifications depuis le début, simplement étendues semble-t-il).
Expliquer en un commentaire que la journalisation ext ne sert à rien, alors que c'est l'évolution majeure entre ext2 & ext4.

À moins que ce soit du pur troll ? :non:
votre avatar
Sur ce lien, tu verras qu'en lecture et écriture sur de moyens et gros fichiers, Fat / ExFAT est légèrement plus rapide.

Lors de lecture et l'écriture de petits fichiers, par contre, c'est NTFS qui remporte la course.

EDIT : Et je n'ai absolument rien dit concernant la journalisation, je ne sais pas d'où tu sors ça ? Et pour la fragmentation, tu veux me faire dire ce que je n'ai pas dit ?

Je parle uniquement de vitesse pure, rien d'autre.
votre avatar
J'ai du mal avec l'argument du stockage d'un propriétaire avec un ID numérique : comment veux-tu stocker les informations de propriété autrement ?
Tout ID n'a nécessairement qu'une signification locale, sauf si tu l'inscrit dans un référentiel universel (ce qui est nécessaire pour que des UID deviennent des UUID - GUID chez M$). C'est évidemment bien souvent inapplicable.
votre avatar
C’est pour ça qu’un système de fichier anonyme (qui ne stocke pas d’information de propriétaire) est plus adapté pour des périphériques nomades. Le problème n’est effectivement pas tant la manière dont c’est stocké, que le fait que ça ne puisse pas être partagé convenablement d’une machine à l’autre.

Pour répondre à ta question, on pourrait imaginer stocker les droits avec un nom, ça donnerait l’illusion que ça marche si le nom est le même. Ça poserait tout autant de problème, mais serait peut-être plus intuitif pour les non-informaticiens.
votre avatar
FAT32 ? Il y a encore des utilisateurs pour ça ?
votre avatar
Je ne doute pas que tu en fais partie, d’ailleurs. Fais le tour de toutes tes clefs USB et autres supports de stockage : tu en as forcément en FAT32 (ou ils l’étaient au moins d’usine).

Oh, et si tu as un PC récent en UEFI : FAT32 est le FS de la partition EFI, donc tous les gens ayant des PC avec UEFI sont de facto des utilisateurs de FAT32.
votre avatar
En fait, les PC récents ont plus de chance d’avoir au moins une partition FAT32 que les vieux tromblons. :mad2:
votre avatar
C’est tout à fait ça, cher homonyme ! :yes:

(J’avoue avoir buggué une seconde en lisant la notification : « Triton vous a répondu ! »… :transpi: )
votre avatar
J'ai dû formater une carte SD en FAT32 pas plus tard qu'il y a trois jours pour les besoins du hack Wii U (en mode vWii c'est le système de fichier recommandé pour le stockage d'ISO / WBFS pour USB Loader GX et Nintendont).

Windows 11 : Microsoft abolit la limitation de 32 Go en FAT32, sous conditions

  • Du FAT32 à 2 To pour les Insider sous Windows 11

  • Une boite de dialogue temporaire… pendant 30 ans

Fermer