🚀 go-pugleaf

Antoine Leca wrote:

> En <news:dg8p06$gpk$1@reader1.imaginet.fr>, Charlie Gordon va escriure:
>> A partir de Windows 95, M$ se croit malin et ajoute un patch
> 
> Cela a commenc� bien avant. HPFS (1988 ?) avait d�j� un syst�me de
> fichiers avec des noms enregistr�s avec leur casse, si je me souviens
> bien. Sans compter bien s�r que HFS (le syst�me de fichiers de MacOS,
> 1985) l'avait lui
> aussi (y'a un  rapport ? ;^))

Ils n'ont pas invent� le concept, mais l'implementation dans VFAT est
particuli�rement sordide.

> La grosse nouveaut� de VFAT (apparu je crois avec NT3.5 sur des volumes
> NTFSv1.? ; devait avoir un autre nom ;-)), c'�tait la � cohabitation �
> entre les noms longs et les noms � courts � au format 6~1.3 ; c'�tait une
> grosse am�lioration par rapport � ce qu'il y avait avant, o� les
> programmes DOS ne _voyaient_ pas les fichiers d�s qu'ils sortaient du
> cadre 8.3. W95 a rendu cela juste un peu plus sale en faisant que les noms
> 6~1.3 soient visibles de partout... (Le WINFILE.EXE ex-Win3.x sur Windows
> 95, avec lequel on a beaucoup jou� pour cause d'an 2000, �tait de ce point
> de vue-l� un comble.)
> 
> 
>> les caract�res Unicode,
> 
> Non (marche pas bien avec Win9x ; z'ont essay�, mais ce n'�tait pas encore
> cela.)

Oui, mais l'intention �tait l� et l'impl�mentation utilise 16 bits par
caract�re pour le nom long.

>> les dates plus pr�cises
> 
> Oui ; et il y a en plus les dates de dernier acc�s (pour les programmes de
> sauvegarde) et de cr�ation (celle qui manque � Unix.)

Elle ne manque � unix que pour certains FS.

>>                         et sur une plage plus �tendue,
> 
> Hein ?

Oui, ils ont repouss� les limites de la plage des dates support�es ainsi que
la pr�cision.  d'une paire de mots de 16 bits encod�s par champs de bits
limit�s � 1980 sans indication de fuseau horaire et une pr�cision de 2
secondes, ils sont pass�s � une valeur de 64 bits repr�sentant le nombre de
p�riodes de 100ns depuis le 1/1/1601 dans un hypoth�tique calendrier
gr�gorien prolong� que le monde anglosaxon n'a pourtant adopt� qu'en
septembre 1752.  Cette pr�cision est probl�matique : il faut forc�ment
faire les calculs de conversion en 64 bits, et le format est notoirement
inadapt� pour tenir compte des leap seconds.  Le format est donc 10
millions de fois plus pr�cis que la quantit� mesur�e ;-)

>> repousse les limitations de taille des partitions
> 
> Hein ? � quoi penses-tu ? FAT32 n'a rien � voir, et LBA non plus (m�me si
> bien s�r on peut trouver des programmes qui m�langent et qui prennent l'un
> pour l'autre).

Je pensais que VFAT et FAT32 sont apparus en m�me temps, mais peut-�tre pas.

>> Sous unix, la sensibilit� � la casse d�pend du type de syst�me de
>> fichiers utilis�.  La plupart sont case sensitive, mais pas les
>> partitions Windows mont�es avec Samba ou en direct.
> 
> NTFS est capable de diff�rencier la casse (d�pend de l'espace de nom que
> tu choisis, POSIX ou Win32), donc je m'attend � ce qu'un syst�me Unix soit
> capable de le monter sensible � la casse.
> Via SMB/CIFS, je n'en sais rien.

Si tu choisis l'espace de noms POSIX sous NTFS, je pr�dis des probl�mes
insurmontables avec nombre de programmes windows, voire de parties de
windows lui-m�me.

-- 
Chqrlie.