🚀 go-pugleaf

En <news:432835a2$0$22823$636a15ce@news.free.fr>,
    Charlie Gordon va escriure:
> 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
<snip>
>>> 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.

Comme tu dis, y'avait l'intention, mais pas grand'chose d'autre (enfin si,
on peut relire le bon nom sur une machine NT sans se gourrer. D'ailleurs, si
ce truc-l� venait en fait de NT, je ne serais pas outre mesure surpris).


>>> 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.

? �MC, il n'y a que les r�centes versions du syst�me de fichiers de FreeBSD
qui ont les "birthdate" dans les inodes (c'est celui qui s'appelle UFS ?
j'm�lange un peu dans ce domaine).


>>>                         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

Oui. Et en heure locale.

> 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�

Non. Cela, c'est la mani�re que le syst�me a de repr�senter les dates, mais
ce n'est pas ce qui est enregistr� dans le syst�me de fichiers VFAT. Dans
VFAT, la date de modification a �t� �tendu d'un nouveau champ de 16 bits qui
compte si je me rappelle bien des millisecondes (entre 0 et 2000 soit 11
bits efficaces), ce qui augmente effectivement la pr�cision. Mais toujours
en heure locale, et toujours limit� entre 1980 et 2107.


> 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.

Bof. Non et oui. Certains petits malins se sont d�j� amus� avec du temps de
NT3.x (avec les outils Posix ti kit de ressources il n'y a m�me pas besoin
d'aller chercher bien loin) pour cacher /par exemple/ des rootkits derri�res
des noms que Win32 ne sait pas voir.
Alors pour W2K MS a r�agi et a ajout� des API (qui a dit bloat?) qui
permettent aux outils syst�mes au moins d'�num�rer ces horreurs (par exemple
pour les vendeurs d'antivirus, sinon cela donnait mauvais genre).
Il y a des trucs disponibles dans le kit de ressources de W2000 (ou
Sysinternals), ce qui fait que l'on peut maintenant faire la m�me chose avec
XP (qui n'a pourtant pas le sous-syst�me Posix disponible).

Sinon, �videmment ce genre de truc doit facilement exploser Explorer ou
IIS4, mais a-t-on besoin d'aller aussi loin ?


Antoine