Journal Date de fichier

Posté par Nicolas Boulay (site web personnel) le 09 décembre 2008 à 11:11.

Étiquettes : aucune

déc.

2008

Qu'est-ce qu'une date de fichier ?

Je me suis souvent demandé ce que veux bien vouloir dire la date mise à coté du fichier. Je dois juste m'en servir lors d'un "ls -rtl" pour retrouver facilement les fichiers générés à l'instant mais je ne suis guère aller plus loin. Si, il y a bien eu une fois, où j'ai cherché un fichier que je venais d'enregistrer, sans savoir ou, avec find en faisant une recherche sur le "modification time".

Bref, cette date correspond à la dernière écriture du fichier, à sa dernière modification mais aussi à sa dernière copie. Dans ce cas, elle n'indique plus l'age des données contenues mais l'âge du blob de bit ainsi créé (à moins d'utiliser l'option "-p" de cp). Mais quel est l'intérêt de ne pas utiliser '-p' ?

Lors d'une copie depuis internet, la date inscrite est celle du téléchargement et non celle de l'âge des données. Quel intérêt, cela peut avoir ? C'est simplement le plus simple à avoir ?

La plus part des appareils photos sauvegardent maintenant la date en format EXIF dans la photo. Cela permet de résister au copie sauvage sans la date. Mais est-ce que cette date a un intérêt à rester une données externe au fichier ?

La copie et l'écriture sont 2 opérations semblables d'un point de vue techniques mais qui n'ont rien à voir d'un point de vue des données. D'ailleurs, je ne comprends toujours pas pourquoi Linux ne propose pas un fops "copy" pour optimiser les copies et faire du "copy on write" par exemple, ou éviter les aller retour sur un serveur nfs.

Vous servez-vous de ces dates de fichier ?

# make

Posté par niol (site web personnel) le 09 décembre 2008 à 11:28. Évalué à 7.

A mon avis, l'une des utilisations les plus importantes de la modification time, c'est make et tous les systèmes similaires : cela permet de répondre à la question "Qu'est-ce qui a changé et que je dois reprendre en compte?".
- [^] # Re: make
  
  Posté par Guillaum (site web personnel) le 09 décembre 2008 à 21:52. Évalué à 2.
  
  AMHA ce qui prouve qu'un fichier a changé, c'est son contenu et en aucun cas sa date de modification.
  
  Les *remplacents* de make, comme scons, se basent sur un hash du fichier (stocké dans un fichier) pour établir la modification.
  
  En pratique, la date peut etre biasée par enormement de choses (differences d'heures entre les machines, copies, gestionnaire de version, ...), c'est donc une erreur que de s'en servir.
  - [^] # Re: make
    
    Posté par ubitux le 10 décembre 2008 à 09:23. Évalué à 2.
    
    Je me souviens avoir eut des soucis de dates avec des fichiers sur un serveur NFS dont l'heure était anterieur à celle coté client donc je ne pense pas…
  - [^] # Re: make
    
    Posté par Matthieu Moy (site web personnel) le 11 décembre 2008 à 11:10. Évalué à 4.
    
    Oui, mais n'importe quel outil qui cherche à passer à l'échelle va justement tout faire pour éviter de faire le moindre open() sur un fichier, et se contenter d'un lstat().
    
    Make, mais aussi la quasi-totalité des gestionnaires de versions.
# Oubli ?

Posté par Obsidian le 09 décembre 2008 à 11:42. Évalué à 5.

C'est effectivement un oubli « historique » mais il faut bien voir qu'à l'époque où le filesystem a été conçu, les échanges de fichier n'étaient pas ce qu'ils sont aujourd'hui à travers le réseau. Maintenant, rien n'empêche d'utiliser un système de fichier qui propose des extensions permettant de conserver cette date. Surtout que, n'étant par principe jamais modifiée, les overheads qu'elle implique sont quasi-nuls.

Bref, cette date correspond à la dernière écriture du fichier, à sa dernière modification mais aussi à sa dernière copie. Dans ce cas, elle n'indique plus l'age des données contenues mais l'âge du blob de bit ainsi créé (à moins d'utiliser l'option "-p" de cp). Mais quel est l'intérêt de ne pas utiliser '-p' ?

D'un point de vue sémantique, si les données ont été modifiées, alors ce n'est plus les mêmes. La date de modification est donc, de ce point de vue, la « date de création » des données telles que tu les vois. D'autre part, quand tu copies un fichier ou le télécharges, il est utile de savoir à quelle date il est arrivé sur ton disque ... ne serait-ce que pour savoir que c'est bien lui la copie ! C'est aussi fondamental dans le cas des Makefile. En plus, il y a ambigüité : une copie est considérée à juste titre comme un nouveau fichier qui a donc, lui, une date de naissance propre.

Ceci dit, c'est vrai que ça manque, et que ce serait plus utile que les access time et change time.
- [^] # Re: Oubli ?
  
  Posté par Nicolas Boulay (site web personnel) le 09 décembre 2008 à 12:34. Évalué à 3.
  
  D'autre part, quand tu copies un fichier ou le télécharges, il est utile de savoir à quelle date il est arrivé sur ton disque ... ne serait-ce que pour savoir que c'est bien lui la copie !
  
  Quel est l'utilité ? Cette date serait la seul différence avec le fichier d'origine.
  "La première sécurité est la liberté"
  - [^] # Re: Oubli ?
    
    Posté par theocrite (site web personnel) le 09 décembre 2008 à 13:07. Évalué à 4.
    
    Ben par exemple tu as téléchargé un truc hier, tu ne sais plus quel est le nom. Tu fais un ls -altr, tu peux avoir le fichier rapidement. Si c'était la date d'origine, ça ne serait pas trié par date d'arrivée sur le disque dur.
    
    Un autre exemple, j'ai des serveurs où je fais pas mal de wget dans le /tmp, mais je ne les redémarre jamais. Du coup un ls -altr /tmp me permet de savoir quels sont les plus récents arrivés sur le disque, ce sont eux les candidats les plus sérieux à la suppression.
  - [^] # Re: Oubli ?
    
    Posté par liberforce (site web personnel) le 09 décembre 2008 à 14:50. Évalué à 9.
    
    Posons le problème autrement. La copie c'est du clonage. Si tu clones quelqu'un, quelle est sa date de naissance ? Celle de l'original, ou celle où est apparu le clone ? Pour moi c'est celle o* a été créé le clone, et qui permet de connaître son âge réel. Ton fichier, bien qu'étant une copie exacte de l'original, n'en reste pas moins un fichier différent, avec sa propre vie/mort. Le cas où il partage toutes les caractéristiques, c'est que c'est le même individu, et c'est du hard link.
    - [^] # Re: Oubli ?
      
      Posté par Dysen le 09 décembre 2008 à 17:08. Évalué à 1.
      
      Il me semblait que dans le cas du clonage les cellules du clone avaient le même état de fatigue / vieillesse que l'être original. Du coup l'age réel du clone n'est plus vraiment celui de sa date de création.
      - [^] # Re: Oubli ?
        
        Posté par Thomas Douillard le 09 décembre 2008 à 17:14. Évalué à 6.
        
        C'est quoi, l'age réel ?
        
        [^] # Re: Oubli ?
        
        Posté par liberforce (site web personnel) le 09 décembre 2008 à 19:08. Évalué à 3.
        
        L'âge est compté à partir du moment où un nouvel organisme est créé. Sinon, je pense qu'on parlerait d'âge cellulaire. M'enfin si on commence à parler de l'âge de l'original comme base pour l'âge du clone, on est pas loin de définir notre date de naissance par rapport à celle de nos parents (genre la moyenne), ce qui me semble idiot.
        
        [^] # Re: Oubli ?
        
        Posté par windu.2b le 09 décembre 2008 à 21:42. Évalué à 3.
        
        La fin de ton raisonnement est fausse : il faudrait faire la moyenne d'âge entre l'ovule de la mère (qu'elle a dès sa naissance) et le spermatozoïde (qui n'a été créé que quelques jours avant la fécondation) du père.
        
        [^] # Re: Oubli ?
        
        Posté par Anthony Jaguenaud le 10 décembre 2008 à 10:46. Évalué à 3.
        
        Il faudrait même calculer, non pas par rapport à la naissance de la mère, mais par rapport à la création des ovules pendant l'état embrillonaire de la mère...
        
        Mouai ==>[]
    - [^] # Re: Oubli ?
      
      Posté par Matthieu Moy (site web personnel) le 11 décembre 2008 à 11:18. Évalué à 2.
      
      Sous Unix, justement, il y a les deux dates : mtime (Modification) et ctime (Change).
      
      On peut tricher facilement sur le mtime (touch permet de le modifier, cp -a le conserve, tar xf le restaure, ...), mais difficilement sur le ctime, qui correspond de manière bien plus fiable à la date de dernier changement sur le inode du fichier (certaines opérations comme créer un lien en dur modifient le ctime et pas le mtime).
      
      Pour voir les deux : ls -l et ls -l --time=ctime.
  - [^] # Re: Oubli ?
    
    Posté par Obsidian le 09 décembre 2008 à 15:02. Évalué à 4.
    
    C'est surtout que cette date a un sens au niveau du fichier lui-même en tant qu'entité, pas vis-à-vis de son contenu.
    
    Ceci introduirait d'ailleurs encore une nouvelle date : la naissance des données que le fichier contient est-elle la même que celle du fichier initial ? La réponse est oui dans le cas de l'EXIF car ton APN stocke directement la photo qu'il vient de prendre sous forme de fichier, mais dans le cas d'un PDF ou d'un fichier scanné, il faudrait conserver la date de rédaction du document. La première différence est que celle-ci est plus difficilement déterminable par un ordinateur.
# hummm

Posté par nullisimo le 09 décembre 2008 à 11:48. Évalué à 2.

Autant l'atime (acces time) n'est pas d'une grande utilite, a part pour se rendre compte de la quantite de donnees qui sont accumulees et non utilisees, autant le couple ctime/mtime est vital. Ne serait-ce que pour faire des backups incrementaux, des check basiques sur l'integrite de fichiers. Et reperer les petits malins qui font des betises et changent le mtime pour les camoufler ;-)
- [^] # Re: hummm
  
  Posté par Nicolas Boulay (site web personnel) le 09 décembre 2008 à 12:32. Évalué à 2.
  
  Tu voudrais plutôt un hash en fait ?
  "La première sécurité est la liberté"
  - [^] # Re: hummm
    
    Posté par nullisimo le 09 décembre 2008 à 13:37. Évalué à 6.
    
    j'ai du mal a saisir le sens de la remarque, desole.
    Le hash c'est tres bien, mais c'est pas specialement ce que l'on fait de moins couteux ;-)
    Meme si j'ai bien la signature de mes fichiers lors du backup, verifier ~ 25 millions de fichiers n'est pas ce qu'on appeller une aide rapide a la decision. 98% de nos fichiers ont mtime==ctime. Il est arrive que certains de mes collegues "maquillent" le mtime pour camoufler une operation (c'est une fausse bonne idee typique) et eviter que ca se remarque plus tard (lors des migrations aux archives par exemple). Une preselection via ctime/mtime permet de mettre le doigt sur 95% des problemes en quelques heures, plutot que de verifier les hashes 9To de donnees.
    - [^] # Re: hummm
      
      Posté par Matthieu Moy (site web personnel) le 11 décembre 2008 à 11:20. Évalué à 2.
      
      (j'ai déjà vu un étudiant avoir un fichier avec mtime < ctime et prétendre qu'il avait fait ce fichier lui-même avec un éditeur de texte ;-) )
- [^] # Re: hummm
  
  Posté par 태 (site web personnel) le 09 décembre 2008 à 17:37. Évalué à 2.
  
  Le atime, je m'en sers parfois quand j'ai une suite de fichiers que je lis petit à petit et que je ne me souviens plus de celui que j'ai lu en dernier (en l'occurence, c'était pour une série de podcasts que j'avais téléchargés en gros). Malheureusement, pour que ça marche vraiment, il faut que personne d'autre n'y accède (updatedb, c'est à toi que je pense et que j'ai du désactiver sur une partition). Et j'ai toujours dans mon zshrc les alias
  
  alias jour='ls *(a-2^/)' #fichiers lus ces 2 derniers jours alias recent='echo *(oa[1,3]^/)' #3 fichiers les plus récemment lus
  
  Depuis que j'ai mis une partie de mon système en noatime, je me suis rendu compte que mutt aussi se sert du atime pour savoir si les mails ont été lus depuis la dernière modif. Il y a certainement d'autres usages moins anecdotiques, non ?
# Parce que c'est une méta-donnée

Posté par benoar le 09 décembre 2008 à 12:26. Évalué à 2.

La plupart du temps où tu "perds" la date (téléchargement, etc ...) c'est parce que celle-ci fait partie des méta-données, et pas des données elle-mêmes. Et comme la plupart du temps, les protocoles/formats n'ont pas été fait de manière à s'échanger les choses de manière 100% identique en dehors des données elle-mêmes, et bien il y a certains trucs qui sautent. Cf les copies d'ext2/3 vers du fat32, le téléchargement, la copie depuis samba, etc ...
# Fichier != document ...

Posté par Thomas Douillard le 09 décembre 2008 à 12:28. Évalué à 4.

Les dates dont tu parles genre la date de prise de vue, la date de création d'un document, sont amha très différente des dates de "fichier".

Je m'explique, un document peut "vivre" en version papier, électronique, être copié, etc. On voit bien que la version imprimée d'un pdf n'a rien a voir avec le fichier (dans le sens système de fichier) pdf qui a servi a le générer.

Donc ce genre de document est souvent daté "a l'intérieur des données" sous forme textuelles directement genre une date sur une page du pdf, ou sous forme de métadonnées internes au document, exif par exemple pour les images, ou autre format pour un odt.

Il y a peut être de la place pour les métadonnées additionelles au niveau du FS, le gros problème étant à mon sens que les protocoles de transmissions genre ftp ne gèrent pas les métadonnées au niveau FS ...
# wget

Posté par Mildred (site web personnel) le 09 décembre 2008 à 12:35. Évalué à 2.

Il me semble que wget conserve la date du document. J'ai pu m'en rendre compte car j'ai un dossier spécial ~/Inbox qui sert à recevoir tous les téléchargements que je fais. Et je le trie par date.
Les fichiers téléchargés par firefox viennent s'ajouter à la fin, mais avec wget, c'est au milieu.
# date externe

Posté par fcartegnie le 09 décembre 2008 à 17:25. Évalué à 2.

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.
# C'est ce que je croyais aussi...

Posté par _PhiX_ le 09 décembre 2008 à 20:01. Évalué à 3.

Lors d'une copie depuis internet, la date inscrite est celle du téléchargement et non celle de l'âge des données.

...avant de constater que j'ai sur ma machine des fichiers datant de 1996, date à laquelle je n'avais ni accès à internet, ni PC.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.