Pour moi c'est cohérent d'avoir une date externe (dans le fs).
La date est une propriété relative au système, et dépend donc du système (à l'heure, pas à l'heure...): ce n'est qu'une information pour le système de fichiers. Le contenu même (entrées dans le fs) est indépendant et peut donc contenir sa vraie date.
Une copie est une écriture, du point de vue fs, donc c'est toujours cohérent que la copie ait une nouvelle date.
Quant au copy on write, sauf si c'est un copy on truncate, c'est aussi le moyen pour éviter la fragmentation. On a un fichier nouveau qui ne tiendra jamais dans les blocs contigus précédents alloués (FAT...). A partir de ext2, les fs linux utilisent la préallocation qui évite justement ce problème et permet de reserver qq blocs de plus pour le fichier. Peut être une raison, avec la croissance exponentielle des tailles, que personne n'y songe.
# date externe
Posté par fcartegnie . En réponse au journal Date de fichier. Évalué à 2.
La date est une propriété relative au système, et dépend donc du système (à l'heure, pas à l'heure...): ce n'est qu'une information pour le système de fichiers. Le contenu même (entrées dans le fs) est indépendant et peut donc contenir sa vraie date.
Une copie est une écriture, du point de vue fs, donc c'est toujours cohérent que la copie ait une nouvelle date.
Quant au copy on write, sauf si c'est un copy on truncate, c'est aussi le moyen pour éviter la fragmentation. On a un fichier nouveau qui ne tiendra jamais dans les blocs contigus précédents alloués (FAT...). A partir de ext2, les fs linux utilisent la préallocation qui évite justement ce problème et permet de reserver qq blocs de plus pour le fichier. Peut être une raison, avec la croissance exponentielle des tailles, que personne n'y songe.