Bonjour,
 
J'aurai voulu savoir s'il était possible de retrouver le nom d'un fichier à partir d'un FILE*, après avoir ouvert le fichier avec un fopen ?
 
 
Merci.

 
Pas à ma connaissance... ce qui est à mon avis plutôt normal. En général, celui qui fait du "fopen()" est sensé savoir ce qu'il y a dans les parenthèses...  

Non. On est censé savoir ce qu'on fait ou prendre des notes...

et non personne ne le sait!!! meme le systeme lui meme ne le sait pas  
dailleurs qd tu fait fwrite il va ecrire un peu nimporte ou et par hasard c sur ton fichier!
 
bravo tu doit ecouter tout c gens!
 

 

 
Le "système" n'a pas besoin du nom d'un fichier, son emplacement lui suffit.

Et ca renverrait quoi pour stdin / stdout / stderr ?

Tu veux dire quoi, par "renvoyer" ?  
Tu es dans l'hypothèse où une méthode existerait pour retourner le nom d'un fichier à partir d'un FILE* ?
 
Si oui, sous Unix ça renverrait /dev/stdin, /dev/stderr et /dev/stdout

Sous DOS/Windows :

• stdin : "con" en mode "r"
• stdout : "con" en mode "w"
• stderr : euh...

Mais comme les 2 premiers, au moins, sont redirigeables soit sur la ligne de commande avec < ou >, soit avec freopen(), ben, c'est pas si simple...

Et si la sortie du programme est redirigee vers l'entree d'un autre (pipe) ?  
 
edit : grilled par edition

   c'est pas parce que le systeme le sait qu'il y a forcement un moyen pour ton programme de le savoir, encore moins si tu veux recuperer cette information de maniere standard...

 
Bien sûr que si.
Surtout en ring 0 sous Windows.
 
Pour la queston, oui, on peut (sous Windows toujours, linked list des handles)

Suffit de générer une chaine aléatoire assez grande, de l'écrire dans le fichier et de scanner tout le disque dur à sa recherche

Ce que je voulais dire c'est justement qu'en fonction de la couche dans laquelle tu te trouves il y a des choses auxquelles tu n'accedes qu'indirectement. Et il ne suffit pas d'avoir acces a toute la mémoire pour récuperer n'importe quelle information.

Bonsoir,
Sous Windows, il existe la fonction getFullPathName(HANDLE,...) qui permet de retrouver le nom du fichier. Reste a voir si HANDLE et FILE sont compatible...

 
Peux-tu expliquer, en gros, comment cela fonctionne, s'il te plait ?
 
Edit02 :
 
Parce qu'apparemment, même les gars de SysInternals ne savent pas faire. Et pourtant, FileMon utilise un driver.  
http://www.microsoft.com/technet/s [...] n.mspx#EBE
 

 
Traduction :
Le coeur de FileMon est un driver. Une table de hash est utilisée pour faire le lien entre le handle du fichier et son nom. Si un fichier a été ouvert avant que FileMon ne démarre, il ne pourra pas le retrouver dans sa table de hash et ne pourra pas afficher son chemin mais seulement son handle.
 
Sans être sûr à 100% que cela ne soit pas possible, je pense que s'il existait un moyen, ces gars l'aurait utilisé. Donc, marctes, si tu connais une façon d'y arriver, je te serais infiniment reconnaissant de nous l'expliquer.    
 
***********
 

Hmmm... D'après la MSDN, le premier argument n'est pas un handle mais le nom du fichier dont on veut retrouver le chemin.

 
Edit01 :
 
Et pour répondre à ta question, un HANDLE est un numéro identifiant un "objet" ouvert par windows (Fichier, contexte d'affichage, adresse de dll, fenêtre, etc.). Alors qu'un FILE est une structure utilisée par la lib C. Cela n'a donc rien à voir.

 
Argh j'ai du mal des fois!!
 
en fouillant mon stdio.h, voici la definition de FILE (issus de VC 2005 express):

The question is: _tmpfname contient quoi?
EDIT: bon apres investigation sur google, ca marche pas non plus:
http://www.experts-exchange.com/Pr [...] 78041.html

Bzzt ! Il n'y a pas de "la définition de FILE". FILE n'est pas définit par le langage C autrement que comme un type opaque. Chaque implémentation fait ce qu'elle veut.

Tu as montré une implémentation de FILE, je pourrais t'en montrer d'autres...
MinGW :

(qui ressemble étrangement à ta version 'visual C++ express', tu es sûr de ton coup ?)

Il faudrait dessasembler fread pour voir ce quil fait de FILE* pour retrouver le HANDLE windows (il doit forcement aller le chercher qqpart avant de la passe a lapi windows) .  Apres un coup de GetFullPathName() et le tour est joué (bien sur c pas portable mais bon)

Je sais, c'est pourquoi j'ai preciser qu'elle venait de vc2005 express
 
 

Salut.
Le systeme fait forcement la liaison entre un nom et un filedesc, pour linux ça sera filedesc inode, inode nom de lien donc fichier.
Voir fstat pour l'inode.
Sous windows je sais pas par ou on passe.
Le problème est que trouver le nom du fichier revient à ecrire un petit programme.

Le problème de fstat() c'est qu'il utilise un descripteur de fichier posix, obtenu avec open().
 
Les autres fonctions stat() et lstat() fonctionnent avec un chemin.

 
Ce n'est pas parce qu'on peut retrouver une info à partir d'une première que l'inverse est "forcément" vrai. Le système n'a pas besoin de connaitre le nom du fichier pour travailler dessus, par contre, l'utilisateur oui. Donc le système doit savoir retrouver l'adresse du fichier à partir de son nom mais il n'a pas besoin de retrouver le nom à partir de l'adresse. Rien n'indique que sela soit possible.
 
Exemple :
 
Un programme (win32) utilise la fonction GetLastError exporté par la bibliothèque Kernel32.dll. Pour retrouver son adresse, c'est très simple, il suffit d'appeler GetProcAddress(Kernel32_hModule, "GetLastError" ). Mais là, surprise ! L'adresse renvoyée est celle de la fonction RtlGetLastWin32Error exportée par NTDLL.dll. Ca s'appelle les fonctions Forward, déclarées dans Kernel32 mais dont le code se trouve dans NTDLL (l'utilité de cette méthode est de fournir une api uniforme sous NT comme sous 9x). En fait, dans la table d'export de Kernel32, là où il devrait y avoir l'adresse de la fonction, il y a l'adresse d'une chaîne de la forme "ntdll.RtlGetLastWin32Error" pour indiquer que c'est une fonction forward.
 
Le truc, c'est qu'à partir de l'adresse, on ne pourra pas retrouver le nom kernel32.GetLastError qui est le vrai nom de la fonction utilisée par le programme, présent dans sa table d'imports.
 

Accessoirement un n° d'inode peut ne correspondre à aucun fichier

 
Ben fait un printf("%s", fp->_tmpfname)...

Accessoirement, c'est quoi l'interet de la manip?  
Et pour red faction, je rappelle la declaration de GetFullPathName :

 
Il est ou le handle dans l'histoire ?
 

jmettais fié a ce post, ...

Je suis d'accord avec toi Anordem le système n'en a pas besoin ( du nom de fichier), mais il en donne la possibilité à l'utilisateur.  
Le système est capable de fournir à l'utilisateur ce type de données, aprés par ou il faut passer c'est autre chose.
Mais le raisonnement et tout de même logique si il peut nous fournir nom et filedesc lié l'un et l'autre peuvent être retrouvés à partir d'un seul.
C'est une opinion mais je doute que la manip soit impossible.

ou alors tu capte tout les CreateFile et tu fait une table handle<->fichier,  
 
apres obtient le handle dapres le file* puis le nom
mais
-cest compliqué
-cest pas portable
-tu ne peut avoir le nom du fichier que si tu as intercepté le createfile avant

Ou alors tu as un cerveau qui dépasse le cap des 2mn non volatile et t'arrives à te souvenir du nom que t'as mis dans les parenthèses...

heu c pas moi qui veut ca  
rien a foutre de connaitre le nom fichier ouvert avec FILE*

Oui oui, désolé du quiproquo. J'ai juste renchéri sur ton post pour répondre à sangohan001 (qui, soit dit en passant, n'a jamais plus rien dit ici).
Si ça se trouve, il doit modifier un programme C mono source et mono fonction complètement moisi où il y a écrit "fopen(toto, ...)" en ligne 12680 et comme il ne veut pas se casser le c... à essayer de remonter l'origine de "toto" dans le fatras de son code tout pourri il cherche à rajouter cette verrue supplémentaire...

Et pourtant! mais sous Windows. Sans compter que « vista » implémente une méthode qui le fait : GetFileInformationByHandleEx.

Quel rapport avec le FILE* ? S'il n'a pas un HANDLE, c'est crâmé

 
Merci pour l'info.    
A noter cependant que GetMappedFileName n'est disponible que sous système NT dans la bibliothèque Psapi.dll. Mais c'est déjà pas mal.  
 
D'après mes quelques tests, un indice permettant de retrouver le HANDLE renvoyé par CreateFile est stocké dans FILE._file. Cependant, il n'est pas du tout sûr que cela soit toujours le cas (du moins, qu'il soit toujours à la même place). Ensuite, il faut manipuler un tableau de structures pointé par __pioinfo (exportée par msvcrt.dll). Je n'ai pas trouvé la définition de cette structure (je n'ai pas beaucoup cherché) mais il est fort possible qu'elle change d'une version à l'autre. D'après le code désassemblé, la structure fait 36 octets, soit 9 DWORDs. Le code suivant permet de retrouver un HANDLE à partir d'un FILE mais comme il utilise des structures internes non documentées, il peut ne pas fonctionner sur d'autres machines. Et ça n'est valable que pour windows.
 

 
Donc tout ceci reste plutôt bancal.

Prochain concours : comment retrouver l'addresse d'un int a partir de sa valeur. Stay tuned ...

 
"pioinfo" c'est franchement pas tellement loin de "pipoinfo"...    
 
 

Euh... ça compte si on arrive à faire le contraire (trouver la valeur à partir de l'adresse) ???

C'est comme si tu me demandais "et si j'arrive a trouver un FILE* a partir d'un nom de fichier, est-ce que c'est bon?"    

Bah j'aime bien regarder ce qu'il se passe sous le capot... Et voir comment tout ça fonctionne. Mais je comprend que ça n'intéresse pas grand monde...  
N'empêche qu'une question a été posée et ceux que ça intéresse ont une réponse.

N'empêche que tous ceux qui savent utiliser un FILE* n'ont jamais eu besoin d'avoir de réponse à cette question...