Je code un truc qui accède à des fichiers un peu partout, en ram, en flash, dans différents répertoires, et ces fichiers sont ou passés en arguments, ou découverts durant l'exécution du programme. Bref, ils peuvent être n'importe où. Evidemment, il faut que je garde une trace des fichiers : "où est le fichier que j'ai utilisé tout à l'heure ?"
La réponse, malheureusement, me semble être "sans le chemin complet, tu perdras ton fichier". Le but étant d'éviter d'utiliser SymFindFirst/SymFindNext parce que c'est bien lourd. Faisons le tour des possibilités :
1. On garde le handle du fichier pour l'identifier. Ca semble attractif, l'identifiant étant absolument unique. Oui, mais problème : impossible de retrouver facilement le nom complet du fichier. kernel::Hd2Sym renvoie une SYM_ENTRY*. Donc si on veut savoir à quel répertoire ça appartient, c'est mort. En effet, une SYM_ENTRY ne donne aucun renseignement sur le répertoire, ce n'est en effet pas un HSym. Et plein de fonctions de vat.h fonctionnent avec une SYM_STR, ce qui impose de connaitre le répertoire si on est pas dans le répertoire courant
2. On garde un HSym. Ca a l'air parfait comme ça, mais dès qu'on ajoute ou supprime un fichier dans le répertoire contenant un fichier dont on a le HSym, ce dernier devient invalide, ce qui se produit sans cesse dans mon programme. Donc exit le HSym, fausse bonne idée.
3. On garde le nom complet. Là, ça marche. Mais ça veut dire qu'à chaque fois que le programme ouvre un fichier dont il trouve le nom ici où là, il doit vérifier s'il y a un chemin, au cas où il n'y en a pas, y concaténer le répertoire courant (ou un autre, genre, euh, include ou obj par exemple), et ensuite faire des SymFindPtr. C'est coûteux en plus d'être la solution la plus chiante à mettre en place.
4. J'ai cherché aussi un moyen simple en stockant les handles des répertoires et des fichiers, puis en reconstruisant tout ça à coup de tios::SymFindHome / kernel::Hd2Sym, mais encore une fois c'est pas simple, ça double le travail d'enregistrement des références d'un fichier, et c'est aussi chiant à accéder
5. On utilise le ramcall char* kernel::Hd2FullPath (HANDLE hd, char* buffer). Et là, c'est la fin des emmerdes. Encore une fois, le kernel fait tout, mais ça on le savait déjà.
Exemple concret de cas où ça fait bien chier :
On lance un programme, au pif as abc def ghi\abc
Si on ne retiens les handle, la solution qui parait donc la meilleure, on a en fait deux fichiers "abc" avec deux répertoires différents. Hors quand on va vouloir accéder à ghi\abc, on va faire quoi ? kernel::Hd2Sym(Handle). Le problème, c'est que le kernel retourne alors la SYM_ENTRY, qui commence par "abc",0, et qui surtout ne donne aucun moyen de retrouver le répertoire !. Et là, quand on va faire des opérations à partir de cette chaine (comme EM_moveSymTo/FromExtMem et tant d'autres romcalls en fait), ben on va se tromper de fichier, on va travailler avec le abc du répertoire courant.
Les deux seules solutions viables consistent donc :
- soit à retenir les chemins complet : chiant pour les raisons évoquées
- soit à retenir le handle et à se taper un SymFindFirst/SymFindNext. C'est exactement le boulot que j'aimerais que le kernel fasse, en fait
Mais il y a encore une autre raison, bien plus perverse :
Je travaille avec des handles, qui peuvent appartenir subitement à des fichiers temporaires (pedrom::tmpnam) et donc à la vat, s'ils sont swappés en flash. Je n'ai aucune raison de retenir le nom de ces fichiers, vu qu'ils sont créés dans le répertoire courant, et qu'ils seront effacés avec pedrom::unlink (kernel::Hd2Sym (hd)) à la libération du handle. Le reste du temps, je me fiche de leur nom, il n'est là que pour archiver les handles.
Mais mes fonctions ne peuvent pas le deviner, ça, donc elles ne peuvent pas utiliser kernel::Hd2Sym sur n'importe quel handle, si par exemple elles veulent désarchiver un fichier. Ca marchera pour un fichier temporaire, puisque créé dans le répertoire courant, mais pas pour un "vrai fichier" qui ne sera pas effacé à la fin du programme. Au mieux, le mauvais fichier sera déswappé (et le fichier auquel on voudra accéder sera encore en fait en flash, donc on se tapera une erreur de protection), au pire le fichier ne sera pas trouvé, car dans un autre répertoire.
Et là, si je dois retenir des chemins complets pour des fichiers temporaires, alors que je ne travaille en réalité que sur les données du handle, en me foutant complètement de ce qui se passe dans la vat, je suis pas sorti de l'auberge.
Parce que évidemment, mon système de swap rend toutes ces manipulations complètement transparentes pour le core du programme (j'ai juste wrappé HeapAlloc/HeapRealloc/HeapFree), et je voudrait évidemment continuer à travailler avec des handles, surtout pas des noms de fichiers temporaires, peut-être existants, mais peut-être pas !
)
. Sinon, c'est pas la peine de tester le retour de SymFindFirst, c'est forcément un répertoire, en FO_RECURSE, je me trompe ?)
C'est pas bien de mentir.)
)
)
