Discussion :

[Fl0r3nt]

Bonjour,

Je souhaiterai pourvoir stocker des fichiers dans un fichier.
Je note l'index des octets dans un fichier d'entête.
Ensuite, je lis le fichier à l'aide de l'entête et j'envoie tout dans une variable.

Si dans cette variable, j'ai le contenu d'un document, pdf ou doc.. ou autre.
Comment le lire sans l'écrire sur le disque dur ?
Le mieux serait de l'ouvrir avec le logiciel par défaut prévu dans le système hôte.

Vers quels modules dois-je chercher ?
merci.

[tyrtamos]

Bonjour,

Regarde déjà du côté des modules tarfile et StringIO.

Tyrtamos

[Fl0r3nt]

Tarfile est intéressant si je veux stocker des informations dans un conteneur. Par contre, je ne trouve pas comment laisser ce conteneur en mémoire.

Idem pour StringIO ou cStringIO, cela permet de créer des contenus de fichiers mais sans réellement les créer. Pour cela, il faut les enregistrer sur le disque dur.
Sauf, si ces fichiers sont des images, mais ce n'est pas tout le temps le cas.

Êtes-vous d'accord ?
Avez-vous d'autres pistes ?

Merci par avance.
ar.

[wiztricks]

Salut,

In fine, le contenu des fichiers devra être adressable via des variables qui pourront être des objets StringIO si on souhaite disposer de l'API "fichier".

Quel est l'intérêt de les mettre dans un conteneur .ZIP ou .TAR si c'est pour le garder en mémoire: un dict pourrait suffire, non?

- W

[PauseKawa]

Bonsoir,

Idem pour StringIO ou cStringIO, cela permet de créer des contenus de fichiers mais sans réellement les créer. Pour cela, il faut les enregistrer sur le disque dur.

Voici une réponse sur le sujet (Sujet, origine)

Salut,
Hmm plutôt que de passer par subprocess.stdout => StringIO => subprocess.stdin, pourquoi ne pas laisser le shell (bash) faire le pipe?
- W
PS: Quand c'est trop compliqué, il y a encore la ressource de passer par un ramdisk.

Si vous avez la solution dans ce sens. Merci.

Bon code

[Fl0r3nt]

Salut,

In fine, le contenu des fichiers devra être adressable via des variables qui pourront être des objets StringIO si on souhaite disposer de l'API "fichier".

Oui, je pense pouvoir construire un fichier par le biais de variable, mais si je souhaite utiliser le fichier en tant que tel, il semble obligatoire de d'écrire celui-ci sur le disque dur. Tous les exemples trouvés sur Internet que j'ai essayé écrivent sur le disque dur et ne laisse pas le fichier en mémoire.

Quel est l'intérêt de les mettre dans un conteneur .ZIP ou .TAR si c'est pour le garder en mémoire: un dict pourrait suffire, non?
- W

Il n'y a pas forcement d'intérêt, sauf celui de regrouper des fichiers.

PauseKawa

J'ai lu les posts indiqués et leurs conclusion. Par contre, les RAMDISK sont la plupart payant ou très ancien dans leur développement. La plupart du temps leurs codes source est fermés.
Dans tous les cas, ce n'est pas une fonctionne native dans Python.

Merci de votre aide.

[wiztricks]

[QUOTE]Oui, je pense pouvoir construire un fichier par le biais de variable, mais si je souhaite utiliser le fichier en tant que tel, il semble obligatoire de d'écrire celui-ci sur le disque dur. Tous les exemples trouvés sur Internet que j'ai essayé écrivent sur le disque dur et ne laisse pas le fichier en mémoire./QUOTE]

"En mémoire" correspond à la mémoire RAM allouée pendant la durée de vie d'un process - l'interpréteur Python qui exécute vos scripts - et elle est rendue à la fin du process - et les données qu'elle contient sont perdues.

Si vous ne voulez pas passer par des fichiers disques, vous avez deux solutions (enfin au moins):
- trouver un driver de RAMdisk pour votre OS qui permet d'allouer un chunk de mémoire physique utilisable comme un disque,
- passer par mmap avec ou sans fichier de backing store, c'est une fonctionnalité de l'OS accessible depuis Python mais il vous faudra lire la doc OS pour l'utiliser proprement.

- W

[Fl0r3nt]

Par contre, je comprends que ce n'est pas portable (Windows / Linux).
Mais comment, les développeurs de Truecrypt ont fait ;-)

[wiztricks]

Par contre, je comprends que ce n'est pas portable (Windows / Linux).
Mais comment, les développeurs de Truecrypt ont fait ;-)

TrueCrypt est OpenSource, il vous suffit d'aller voir comment ils ont fait.
Ceci dit, dès qu'on fait des trucs compliqués, performants et collé à l'OS, impossible de ne pas écrire des bouts de code "spécifiques" à chacun.

- W

[Fl0r3nt]

"En mémoire" correspond à la mémoire RAM allouée pendant la durée de vie d'un process - l'interpréteur Python qui exécute vos scripts - et elle est rendue à la fin du process - et les données qu'elle contient sont perdues.

Si vous ne voulez pas passer par des fichiers disques, vous avez deux solutions (enfin au moins):
- trouver un driver de RAMdisk pour votre OS qui permet d'allouer un chunk de mémoire physique utilisable comme un disque,
- passer par mmap avec ou sans fichier de backing store, c'est une fonctionnalité de l'OS accessible depuis Python mais il vous faudra lire la doc OS pour l'utiliser proprement.

- W

Je relisais votre réponse et quelques choses m'interpelle.
'correspond à la mémoire RAM allouée pendant la durée de vie d'un process'
Une commande python = un process ou un script entier = un process.

Ce que je veux dire, c'est que le fichier est donc accessible par un autre programme tant que le script/commande n'est pas terminé(e) ?

[wiztricks]

Ce que je veux dire, c'est que le fichier est donc accessible par un autre programme tant que le script/commande n'est pas terminé(e) ?

Pour des questions de sécurité, l'espace virtuel d'un process est, par défaut, "privé": impossible d'y accéder sans avoir définit les conditions.

mmap est un moyen pour permettre à différents process de "partager" leur espace virtuel. Il est assez primitif pour faire ce qu'on veut... mais si c'est compliqué, il y a du boulot ;-(
- W