Discussion :

[[eMp]]

Bonjour,

En espérant que ce post ne fera pas doublon (je n'ai à priori pas trouvé ce que je cherche dans la FAQ et dans les exemples de sources).

Environnement :
Solaris 8, compilateur SunWorkshop 6.

Je cherche un moyen (si tant est qu'il y en ait un) d'obtenir la date de création (ou de modification) d'un fichier avec une granularité inférieure à la seconde.
Car, à ma grande déception, les champs st_mtime & cie de la structure stat sont de type time_t et expriment les dates en nombre de secondes depuis 1970.

Une granularité de l'ordre de la milliseconde voir même de la microseconde me serait d'une grande utilité.

Je redoute par avance une réponse du type : "cette info ne se trouve pas dans la table des inodes, tu ne l'auras donc jamais

[koala01]

Salut,

Bien que je ne connaisse pas solaris, je crains fort que la réponse que tu redoutes ne soit celle que tu obtiendra...

*Peut etre* pourrais tu envisager d'écrire cette information au début du fichier... voire sur un fichier qui contiendrait le nom de chaque fichier du dossier et l'information?

Je n'ai aucune idée sur la manière de procéder pour obtenir l'information...

Le pire étant que cette informations ne sera récupérable que pour les fichiers qui auraient été générés au départ de ton application... à moins bien sur, de modifier les instructions système de création de fichier...(un peu à la manière d'un gestionnaire de mémoire)

[[eMp]]

Ok merci Koala. Tu confirmes bien ce que, en toute logique, je redoutais.

En fait le binaire en cours de dev doit traiter tous les fichiers présents dans un répertoire sans pour autant les renommer, déplacer ni les modifier en sachant que quelques secondes plus tard il reparcourera le répertoire pour traiter les nouveaux fichiers. Il mémorise la date et l'heure de dernière modification du dernier fichier traité et, au cycle suivant, ne traite que les fichiers plus récents que la dernière date mémorisée.

Le pb est que lorsque plusieurs fichiers ont pu être créés dans la même seconde il y a un risque d'en oublier (ou d'en traiter deux fois en fonction du test).

Finalement nous avons opté pour mémoriser le nom du dernier fichier traité (en plus de la date) et de trier les fichiers par ordre alphabéthique. Avec ces deux critères de tris on devrait être peinard

[koala01]

Ok merci Koala. Tu confirmes bien ce que, en toute logique, je redoutais.

Attention, je confirme... je confrime... C'est vite dit: C'est plutot que, sans connaitre solaris, j'ai pas l'impression que ce soit faisable

En fait le binaire en cours de dev doit traiter tous les fichiers présents dans un répertoire sans pour autant les renommer, déplacer ni les modifier en sachant que quelques secondes plus tard il reparcourera le répertoire pour traiter les nouveaux fichiers. Il mémorise la date et l'heure de dernière modification du dernier fichier traité et, au cycle suivant, ne traite que les fichiers plus récents que la dernière date mémorisée.

Le pb est que lorsque plusieurs fichiers ont pu être créés dans la même seconde il y a un risque d'en oublier (ou d'en traiter deux fois en fonction du test).

Finalement nous avons opté pour mémoriser le nom du dernier fichier traité (en plus de la date) et de trier les fichiers par ordre alphabéthique. Avec ces deux critères de tris on devrait être peinard

Tu ne peus peut etre pas les renommer, mais, peux tu choisir le nom du fichier?

Si oui, tu peux *peut etre* envisager de mettre un "indice" dans le nom...
ex: nom_fich_000001.ext

[[eMp]]

Non non malheureusement je ne peux strictement rien faire sur les fichiers traités.

Ta précaution sur Solaris n'est, à mon avis, pas nécessaire car la structure de la table des inodes est relativement générique et commune à l'ensemble des OS Unix.

Merci encore pour ton attention