🚀 go-pugleaf

"Antoine Leca" <root@localhost.invalid> wrote in message
news:dg9jmf$ppu$1@shakotay.alphanet.ch...
> En <news:432835a2$0$22823$636a15ce@news.free.fr>,
>     Charlie Gordon va escriure:
> > Antoine Leca wrote:

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

Je ne crois pas : sous GNU/Linux avec ext2/ext3 les commandes suivantes me
donnent 3 dates diff�rentes:

ls --full-time -l
ls --time=atime --full-time -l
ls --time=ctime --full-time -l

En revanche, il me semble que l'une d'entre elles est stock�e avec moins de
pr�cision que les autres.

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

Encore pire que je ne pensais.
Qu'en est-il de NTFS et suivants ?

-- 
Chqrlie.