Ca s'appelle un ramfs. Sous linux :

1. mount -t ramfs /tmp/toto /tmp/toto

Sous windows, je ne sais plus comment ca s'appelle, mais je crois que c'etait l'exemple de l'api systeme de fichier presente par sysinternals

sous windows, les gens ont l'air d'appeller ca un ramdisk :
http://support.microsoft.com/default.aspx?scid=kb;en-us;257405
http://msdn.microsoft.comom/en-us/library/dd163312.aspx

j'avais pensé au ramdisk, effectivement. mais ce n'est pas tout à fait ce que je cherche, je pensais plus à un espace de cache pour le programme, le genre créé au lancement et qui disparait à sa fermeture

godrik : -sous windows
Sous linux aussi c'est un ramdisk (comment dans initrd notamment). ramfs c'est juste le nom donné au système de fichier utilisé pour le ramdisk.

caelacanthe : Tu ne peux pas créer un lanceur qui s'occupe de créer le ramdisk avant d'appeler le vrai programme et qui libère tout dès que le vrai programme a été quitté ?

Arf ! Moi la première fois que j'ai utilisé un disque virtuel c'était... sur mon TO8 !
Nostalgie, nostalgie...

"caelacanthe : Tu ne peux pas créer un lanceur qui s'occupe de créer le ramdisk avant d'appeler le vrai programme et qui libère tout dès que le vrai programme a été quitté ? "

je ne sais pas, ca en reviendrait quasiment au même que de fournir la disquette avec l'archive et le décompresseur, et demander à l'utilisateur de faire une installation; ce n'est pas ce que je veux. je voudrais que le programme se lance à partir de la disquette et qu'il ne touche pas au disque dur de l'utilisateur (a part pour les inévitables fichiers de cache de l'OS).

"godrik : -sous windows "
Bah quoi, j'ai utilise windows il y a longtemps. Et d'ailleurs l'api 32 c'est vachement plus simple a utilise que GTK! Si quelqu'un sait en GTK comment attacher un contexte Cairo a un widget (et pas a toute la fenetre) et dessinner dessus, je suis preneur.

cae.. (En fait, je vais le copier coller, je ferais pas d'erreur comme ca). caelacanthe,
Si j'ai bien compris, ce que tu veux est que les nouveaux fichiers d'un repertoire donne aillent dans un ramfs tandis que ceux qui sont deja present restent dans le repertoire physique ?

Ca m'a l'air trop etrange comme comportement pour que quelqu'un ait deja fait ca avant. Note que ca s'ecririat probablement facilement avec fuse. Mais sous windows, je n'ai pas plus d'idee que ramdisk et lien symbolique (ah, mais ce cretin de windows, ne sais pas ce que c'est qu'un lien symbolique)

Fais gaffe, si toi, le modéro, tu te mets à troller je vais plus pouvoir me retenir

pas tout a fait, en fait, j'ai des archives et un décompresseur sur une disquette, qui décompresse les archives et crée les fichiers décompressés à coté (dans son fonctionnement habituel, a part son monstrueux taux de compression c'est un décompresseur de base, si j'ose dire). ce que j'aimerais faire, c'est déplacer (ou copier) le décompresseur et les archives dans un espace en mémoire au lancement de mon programme, lancer les décompressions et pouvoir lire les fichiers dans cet espace mémoire comme s'il s'agissait d'un disque dur pour pas que les librairies que je compte utiliser fassent la gueule au chargement des ressources

sans copier les données sur les disques durs de l'utilisateur sinon c'est trop facile (et ca s'apparente à une installation, et je préfère les programmes qui se lancent sans intallation)

je ne sais pas s'il est possible de faire ça, je m'en remets donc à vous

Je ne sais pas exactement comment fonctionne le ramdisk, mais tu peux certainement en creer un en ligne de commande. A partir de la, il suffit de lancer l'application par un script qui cree un ramdisk, copie les fichiers sur le ramdisk nouvellement cree et lance le binaire principal. La sauvegarde risque de pose probleme, il faut probablement prevoir de copier certains fichier sur la isquette a posteriori.

"La sauvegarde risque de pose probleme, il faut probablement prevoir de copier certains fichier sur la isquette a posteriori."

il n'est pas prévu de sauvegarde

au pire, je peux toujours m'arranger pour réserver deux-trois clusters a un fichier de sauvegarde, c'est l'intérêt de ce projet, apprendre à économiser la place

mais au fond, comment fonctionnent les loaders d'archives comme celui qu'intègrent irrlicht et ogre? ils mettent des fichiers dans le dossier temporaire de l'OS?

ils travaillent peut etre en ram directement.

C'est facile de décompresser des fichiers en ram, c'est que des gros bytes[] après tout, ce qui l'est pas c'est de permettre à une librairie tierce de localiser le fichier ailleurs que sur disque.
Je vois pas vraiment de solution à ce problème car même si on arrive à faire un boostrapper qui monte un disque en ram, il lui faudra les droits admins et ce sera de la cuisine OS par OS.

En gros si c'est possible, ce sera de la bidouille.

Il y a pas mal de bibliothèque graphique, si c'est de ça dont tu parle, qui peuvent travailler avec des objets en RAM. Il suffit par exemple de les stocker dans le format qu'elles attendent (celui qu'elles produisent quand elles chargent un fichier depuis le disque).

Et même pour monter un véritable système de fichier, sous linux clairement tu n'a pas besoin de droit d'admin pour ce genre de chose si fuse est installé. Sous windows, des outils équivalent qui ne demanderait pas de droit d'admin pourrait exister, mais il n'y en a pas d'aussi canonique. Le driver (open source) qui est utilisé par TrueCrypt pourrait t'intéresser.

j'ai aussi regardé de mon côté, il n'y a apparament pas de vraie solution sous windows pour gérer des répertoires en RAM, sauf passer par un lecteur virtuel, ce qui peut engendrer incompatibilités et complications

mais j'ai examiné à nouveau le code source de paq8px, et si je mets les mains dans le cambouis, je pourrais peut-être adapter sa partie décompression pour qu'elle fonctionne sans répertoire, avec uniquement des ersatz de fichiers en RAM, si ceux-ci se comportent comme des FILE*

mon prof de programmation a évoqué les filemaps (je crois que c'est ça, le mot clé), ca vous dit quelque chose

ah mince, après, il faut encore parvenir a exiger des bibliothèques graphiques qu'elles chargent les données, et généralement elles font ça qu'avec des noms de fichiers, pas des pointeurs sur ces fichiers

@ godrik : http://gnomejournal.org/article/34/writing-a-widget-using-cairo-and-gtk28 ?

Step 2 : « We can get a cairo_t for a GdkWindow (this is what you’re drawing into). You should be aware that a GdkWindow is not like a GtkWindow and that all sorts of widgets have one or more GdkWindows inside them for doing drawing.»

kaoron, j'ai finit par trouver comment initialiser ca comme il faut. Je ferais un post de blog sur cairo a l'occasion. C'est sympa comme truc une fois qu'on a trouve comment l'initialiser.

si quelqu'un se rappelle de la difference entre passer un int* et in int[] en C qu'il se manifeste la bas :

https://www.jeuxvideo.com/forums/1-31-8584399-1-0-1-0-programmation-en-c-pointeurs-et-tablea.htm#message_8584438

Bonsoir! petit casse tête, j'aurais besoin d'un peu d'aide en linux car mes cours sont bien loin

voila la situation:

http://s2.noelshack.com/old/up/arborescence-ee5b0eaf88.png

j'ai une arborescence composée de la manière suivante: un dossier de travail, avec quatres sous-dossiers, qui contiennent chacun quatre sous-dossiers, qui contiennent chacun quatres sous dossiers. Dans ces derniers, il y a un fichier .pov, qui doit être traité par le logiciel de raytracing POVray.

ces dossiers sont nommés de 0 à 3 (oui, je me suis trompé sur le dessin, c'est pas de 1 à 4, mais bel et bien de 0 à 3 )

donc, j'ai 64 fichiers .pov. J'aimerais les traiter avec POVray (suffit de taper la commande povray suivie du nom du fichier) et les effacer au fur et à mesure, juste après traitement. Est-ce possible de faire ça en langage shell?

je suis allé taper sur google, car google est mon ami, mais il ne m'a rien trouvé de bien convainquant, et c'est pourquoi je m'en réfère à vous.

Merci d'avance.