Désolé par avance si ma question vous paraît triviale. J'ai vraiment
cherché sur Google et je n'arrive pas à obtenir la date de création d'un
fichier. Je parle bien de la date de création, pas la date de dernière
modification et de dernier accès.
le 08/11/2010 à 00:47, Francois Lafont a écrit dans le message <4cd73a86$0$1080$ :
Avec touch -m, on peut très bien changer le mtime sans avoir fait aucun changement sur le contenu du fichier.
Ok, mais on pourrait qualifier ce cas de petite exception à la règle en quelques sortes, non ?
Par ailleurs, je constate que la commande chmod provoque une modification du atime.
Pas chez moi (testé dans /tmp qui n'est pas monté avec l'option noatime).
Or, là je ne vois pas trop pourquoi car pour moi le chmod finalement est une modification de l'inode associé au fichier, mais il n'y a pas un accès en lecteur à son contenu il me semble.
Absolument.
-- Benoit Izac
Bonjour,
le 08/11/2010 à 00:47, Francois Lafont a écrit dans le message
<4cd73a86$0$1080$426a74cc@news.free.fr> :
Avec touch -m, on peut très bien changer le mtime sans avoir fait
aucun changement sur le contenu du fichier.
Ok, mais on pourrait qualifier ce cas de petite exception à la règle
en quelques sortes, non ?
Par ailleurs, je constate que la commande chmod provoque une
modification du atime.
Pas chez moi (testé dans /tmp qui n'est pas monté avec l'option
noatime).
Or, là je ne vois pas trop pourquoi car pour moi le chmod finalement
est une modification de l'inode associé au fichier, mais il n'y a pas
un accès en lecteur à son contenu il me semble.
le 08/11/2010 à 00:47, Francois Lafont a écrit dans le message <4cd73a86$0$1080$ :
Avec touch -m, on peut très bien changer le mtime sans avoir fait aucun changement sur le contenu du fichier.
Ok, mais on pourrait qualifier ce cas de petite exception à la règle en quelques sortes, non ?
Par ailleurs, je constate que la commande chmod provoque une modification du atime.
Pas chez moi (testé dans /tmp qui n'est pas monté avec l'option noatime).
Or, là je ne vois pas trop pourquoi car pour moi le chmod finalement est une modification de l'inode associé au fichier, mais il n'y a pas un accès en lecteur à son contenu il me semble.
Absolument.
-- Benoit Izac
Nicolas George
Francois Lafont , dans le message <4cd87cc3$0$2555$, a écrit :
23:35 ~/Bureau
Refais le même essai dans un répertoire qui n'est pas affiché par un environnement graphique ou un gestionnaire de fichiers.
Francois Lafont , dans le message
<4cd87cc3$0$2555$426a34cc@news.free.fr>, a écrit :
francois@franPC 23:35 ~/Bureau
Refais le même essai dans un répertoire qui n'est pas affiché par un
environnement graphique ou un gestionnaire de fichiers.
Francois Lafont , dans le message <4cd87cc3$0$2555$, a écrit :
23:35 ~/Bureau
Refais le même essai dans un répertoire qui n'est pas affiché par un environnement graphique ou un gestionnaire de fichiers.
Nicolas George
Xavier Roche , dans le message <ib9k75$uck$, a écrit :
De moins en moins disponible, car beaucoup de systèmes sont montés avec une option désactivant explicitement la modification de cette information
En fait, ça va un peu plus loin : d'une part, ce changement a déjà commencé à être, il me semble, le défaut du noyau si le contraire n'est pas demandé explicitement.
D'autre part, il y a des modez bizarres, comme relatime, qui met à jour l'atime, mais pas toujours.
Xavier Roche , dans le message <ib9k75$uck$1@news.httrack.net>, a
écrit :
De moins en moins disponible, car beaucoup de systèmes sont montés avec
une option désactivant explicitement la modification de cette
information
En fait, ça va un peu plus loin : d'une part, ce changement a déjà commencé
à être, il me semble, le défaut du noyau si le contraire n'est pas demandé
explicitement.
D'autre part, il y a des modez bizarres, comme relatime, qui met à jour
l'atime, mais pas toujours.
Xavier Roche , dans le message <ib9k75$uck$, a écrit :
De moins en moins disponible, car beaucoup de systèmes sont montés avec une option désactivant explicitement la modification de cette information
En fait, ça va un peu plus loin : d'une part, ce changement a déjà commencé à être, il me semble, le défaut du noyau si le contraire n'est pas demandé explicitement.
D'autre part, il y a des modez bizarres, comme relatime, qui met à jour l'atime, mais pas toujours.
Francois Lafont
Le 08/11/2010 23:55, Nicolas George a écrit :
Refais le même essai dans un répertoire qui n'est pas affiché par un environnement graphique ou un gestionnaire de fichiers.
Ah ! Bien vu Nicolas. Merci beaucoup. :-)
Effectivement, dans ce cas, un chmod ne change pas le atime. Ok, tout s'explique maintenant. J'ai l'habitude de faire des tests sur mon dossier bureau à chaque fois mais là ça m'a joué un mauvais tour. :-)
-- François Lafont
Le 08/11/2010 23:55, Nicolas George a écrit :
Refais le même essai dans un répertoire qui n'est pas affiché par un
environnement graphique ou un gestionnaire de fichiers.
Ah ! Bien vu Nicolas. Merci beaucoup. :-)
Effectivement, dans ce cas, un chmod ne change pas le atime. Ok, tout
s'explique maintenant. J'ai l'habitude de faire des tests sur mon
dossier bureau à chaque fois mais là ça m'a joué un mauvais tour. :-)
Refais le même essai dans un répertoire qui n'est pas affiché par un environnement graphique ou un gestionnaire de fichiers.
Ah ! Bien vu Nicolas. Merci beaucoup. :-)
Effectivement, dans ce cas, un chmod ne change pas le atime. Ok, tout s'explique maintenant. J'ai l'habitude de faire des tests sur mon dossier bureau à chaque fois mais là ça m'a joué un mauvais tour. :-)
-- François Lafont
Tonton Th
On 11/08/2010 11:55 PM, Nicolas George wrote:
Francois Lafont , dans le message <4cd87cc3$0$2555$, a écrit :
23:35 ~/Bureau
Refais le même essai dans un répertoire qui n'est pas affiché par un environnement graphique ou un gestionnaire de fichiers.
Bien vu !
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
On 11/08/2010 11:55 PM, Nicolas George wrote:
Francois Lafont , dans le message
<4cd87cc3$0$2555$426a34cc@news.free.fr>, a écrit :
francois@franPC 23:35 ~/Bureau
Refais le même essai dans un répertoire qui n'est pas affiché par un
environnement graphique ou un gestionnaire de fichiers.
Bien vu !
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
Francois Lafont , dans le message <4cd87cc3$0$2555$, a écrit :
23:35 ~/Bureau
Refais le même essai dans un répertoire qui n'est pas affiché par un environnement graphique ou un gestionnaire de fichiers.
Bien vu !
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
Francois Lafont
Bonsoir,
J'aurais juste une dernière question : je suis surpris qu'après une commande comme 'mv toto titi' (renommage du fichier), le ctime change (et lui seul) ?
En effet, je comprends bien pourquoi que le atime et le mtime ne changent pas, mais je pensais que le ctime n'allait pas changer non plus car il me semble que le nom d'un fichier n'est pas stocké dans son inode, donc pour moi, même après un renommage, l'inode est intact.
-- François Lafont
Bonsoir,
J'aurais juste une dernière question : je suis surpris qu'après une
commande comme 'mv toto titi' (renommage du fichier), le ctime change
(et lui seul) ?
En effet, je comprends bien pourquoi que le atime et le mtime ne
changent pas, mais je pensais que le ctime n'allait pas changer non plus
car il me semble que le nom d'un fichier n'est pas stocké dans son
inode, donc pour moi, même après un renommage, l'inode est intact.
J'aurais juste une dernière question : je suis surpris qu'après une commande comme 'mv toto titi' (renommage du fichier), le ctime change (et lui seul) ?
En effet, je comprends bien pourquoi que le atime et le mtime ne changent pas, mais je pensais que le ctime n'allait pas changer non plus car il me semble que le nom d'un fichier n'est pas stocké dans son inode, donc pour moi, même après un renommage, l'inode est intact.
-- François Lafont
Benoit Izac
Bonjour,
le 10/11/2010 à 00:05, Francois Lafont a écrit dans le message <4cd9d3be$0$9191$ :
J'aurais juste une dernière question : je suis surpris qu'après une commande comme 'mv toto titi' (renommage du fichier), le ctime change (et lui seul) ?
C'est spécifié par POSIX :
| The following characteristics of each file in the file hierarchy shall | be duplicated: | * The time of last data modification and time of last access | [...] | Some implementations mark for update the st_ctime field of renamed | files and some do not. Applications which make use of the st_ctime | field may behave differently with respect to renamed files unless they | are designed to allow for either behavior.
le 10/11/2010 à 00:05, Francois Lafont a écrit dans le message
<4cd9d3be$0$9191$426a74cc@news.free.fr> :
J'aurais juste une dernière question : je suis surpris qu'après une
commande comme 'mv toto titi' (renommage du fichier), le ctime change
(et lui seul) ?
C'est spécifié par POSIX :
| The following characteristics of each file in the file hierarchy shall
| be duplicated:
| * The time of last data modification and time of last access
| [...]
| Some implementations mark for update the st_ctime field of renamed
| files and some do not. Applications which make use of the st_ctime
| field may behave differently with respect to renamed files unless they
| are designed to allow for either behavior.
le 10/11/2010 à 00:05, Francois Lafont a écrit dans le message <4cd9d3be$0$9191$ :
J'aurais juste une dernière question : je suis surpris qu'après une commande comme 'mv toto titi' (renommage du fichier), le ctime change (et lui seul) ?
C'est spécifié par POSIX :
| The following characteristics of each file in the file hierarchy shall | be duplicated: | * The time of last data modification and time of last access | [...] | Some implementations mark for update the st_ctime field of renamed | files and some do not. Applications which make use of the st_ctime | field may behave differently with respect to renamed files unless they | are designed to allow for either behavior.
