Journal Date de fichier

Posté par .
Tags : aucun
8
9
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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 . É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 . É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 (page perso) . É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 (page perso) . É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 . É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 . Évalué à 6.

            C'est quoi, l'age réel ?
            • [^] # Re: Oubli ?

              Posté par (page perso) . É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 . É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 . É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 (page perso) . É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 . É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 . É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 . Évalué à 2.

      Tu voudrais plutôt un hash en fait ?

      "La première sécurité est la liberté"

      • [^] # Re: hummm

        Posté par . É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 (page perso) . É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 (page perso) . É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 . É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 . É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 (page perso) . É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 . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.