seek et tell pour BZIP2 - Page 1

Salut à tous!

Je bloque un peu là.
Les fonctions seek (changer de position dans un fichier) et tell (donne la position actuelle dans le fichier) existent pour des fichier "normaux", des fichiers compressés avec GZIP mais pas pour BZIP2.

Comment faire alors pour connaître sa position et la changer?

On peut pas.

Et soit dit en passant, même avec gzip, leur usage est très fortement déconseillé. Il n'est pas possible de "déplacer" une position dans un fichier. Les fichiers gzip et bzip2 sont des *flux*. A sens unique. Quand tu utilises gzeek, en réalité derrière la bibliothèque rouvre le fichier depuis le tout début, et redécompresse la totalité du fichier jusqu'à arriver à l'endroit que tu as indiqué.

Déjà même sur un fichier normal, il faut éviter ces appels, car ils sont souvent mal compris et non portable. Par exemple, l'utilisation de SEEK_CUR est non portable. De même, appeler fseek avec toute valeur autre qu'une renvoyée par ftell est non portable. En fait pour être exact, les fonctions fseek et ftell souffrent de gros problèmes de portabilité, et l'emploi de fgetpos et fsetpos est recommandé.

et comment tu fais dans un fichier binaire pour enregistrer un offset à partir du début du fichier auquel tu pourras te positionner pour trouver telle ou telle structure ou donnée, par exemple ? (à moins qu'en écrivant le "fpos_t" dans un fichier il reste valide lors d'une prochaine ouverture, je ne sais pas ce qu'il y a derrière ce type)

Tu lis le fichier. De toutes façons c'est la seule façon portable de faire. Utiliser fseek pour ça n'est pas portable (sur certains systèmes, ftell retourne un handle, et fseek n'accepte que les handle retournés par ftell).
C'est également logique, car fseek et ftell sont des anomalies par essence, vu qu'elles brisent l'abstraction des données en tant que flux (et en passant elles feront merder ton programme s'il lit depuis un socket ou tout mécanisme d'ipc).

Comment ça "tu lis le fichier", tu te retapes la lecture depuis le début à chaque fois que tu veux sauter à un offset ? Même si c'est plus propres, ça m'étonne pas que personne ne respecte ça... (bonjour les performances sur des gros fichiers, genre modèles 3D, bsp, etc...)

Non, la sauvegarde d'emplacements est portable. C'est le décalage arbitraire qui ne l'est pas. Autrement dit

x = ftell(f);

fseek(f, x, SEEK_SET);       /* portable */
fseek(f, 42, SEEK_CUR);      /* problème de portabilité  */
fseek(f, x + 42, SEEK_SET);  /* problème de portabilité */

Certains systèmes vont accepter les trois
Certains systèmes, uniquement la première (typiquement les systèmes où ftell renvoie un handle)
Certains systèmes, uniquement les deux premières (idem, mais avec un fseek un peu plus intelligent)

ben "bonjour la performance" quand même sur des gros fichiers, je pense qu'un programme qui a besoin de ça a qd même nettement intérêt à utiliser fseek (même de manière pas 100% portable) plutôt qu'une api propriétaire...

(EDIT : et puis je sais pas de quel standard tu parles, c'est complètement garanti par C89 [pour les fichiers binaires] :

For a binary stream, the new position, measured in characters from the beginning of the
file, is obtained by adding offset to the position specified by whence. The specified
position is the beginning of the file if whence is SEEK_SET, the current value of the file
position indicator if SEEK_CUR, or end-of-file if SEEK_END. A binary stream need not meaningfully support fseek calls with a whence value of SEEK_END.

)

Je n'ai jamais parlé d'une api propriétaire, mais de lire le flux, comme un flux quoi. A moins que tu ne mentionnes fgetpos et fsetpos ? Ah mais ceux là sont parfaitement standard. Juste quelques lignes au dessus de celles que tu cites.

Revenons au centre du problème : je ne parle pas de standard mais de portabilité.

Tiens justement, question standard, on parle bien du même C89 qui définit long int comme type de retour pour ftell ?
Donc t'as déjà des problèmes de portabilité avec les systèmes parfaitement conformes à C89. C'est bien là tout le problème avec ces deux fonctions (ftell fseek), ça ne fait que confirmer ce que je dis depuis mon premier post.

Bah oui mais bon... mettons que je bosse sur un jeu, j'ai mon gros fichier binaire qui contient n'importe quoi, mettons les animations de mon perso, 50mo. Ce fichier contient un tas d'offsets qui me renvoient sur différentes frames de mes animations, parceque je n'ai pas besoin de toutes les animations au même moment et que donc je ne veux pas tout charger à chaque fois. Qu'est-ce qu'il existe comme solution portable pour éviter de se taper la lecture de mon fichier de 50mo depuis le début à chaque fois que je dois me rendre à un offset donné ? (parceque si la réponse est "aucune", bah c'est vite vu : tant pis pour la portabilité)

spectras
: Je n'ai jamais parlé d'une api propriétaire, mais de lire le flux, comme un flux quoi. A moins que tu ne mentionnes fgetpos et fsetpos ? Ah mais ceux là sont parfaitement standard. Juste quelques lignes au dessus de celles que tu cites.

Je parle d'une api propriétaire qui permettrait d'accéder aléatoirement à un fichier ^^ (puisque c'est la seule alternative viable à fseek)

Revenons au centre du problème : je ne parle pas de standard mais de portabilité.

Ben comme dit Zephyr, tant pis pour les rares systèmes qui ne permettent pas de fseek-er à un offset arbitraire... Tu as des exemples ?

Oui. Les systèmes conformes à C89. Dès que le fichier fait plus de 2Go.

Zephyr> non il ne faut pas relire à chaque fois. Il suffit de lire une seule fois, et d'appeler fgetpos à chaque position qui t'intéresse. Tu pourras revenir à cet endroit avec fsetpos par la suite.

Et si j'ai plusieurs structures chainées dans mon fichier ? La structure de type A contient 3500 offsets vers d'autres structures de type B, qui elles même contiennent des offsets vers... etc; ça va devenir absolument immonde comme code :/ (et je n'invente rien, beaucoup de fichiers binaires pouvant atteindre des tailles importantes ont ce genre de structures, voire plus compliqué)

spectras :
Oui. Les systèmes conformes à C89. Dès que le fichier fait plus de 2Go.

- dans l'exemple de bob la taille est connue à l'avance
- c'est un peu gore, mais on peut toujours utiliser plusieurs SEEK_CUR si l'OS travaille en >32 bits en interne ^^ (enfin à vrai dire c'est pas plus gore que si on faisait plusieurs fread, dans la mesure où les fread aussi sont limités)
Et ma question portait là-dessus :

Certains systèmes, uniquement la première (typiquement les systèmes où ftell renvoie un handle) Certains systèmes, uniquement les deux premières (idem, mais avec un fseek un peu plus intelligent)

-> c'est courant ce genre de système ?

Spectras > "Et soit dit en passant, même avec gzip, leur usage est très fortement déconseillé. Il n'est pas possible de "déplacer" une position dans un fichier."
Euh là je ne suis pas tout à fait d'accord. Il est tout a fait possible de se déplacer dans un fichier gzip comme dans un fichier non compressé. Et la doc de gzip propose des fonctions (gz_seek et gz_tell) qui n'ont aucune mention "déconseillé". fgetpos et fsetpos n'existent pas dans l'API à ma connaissance.

Je n'ai pas précisé mais c'est du C++. Pour le cas des fichiers non-compressés j'utilise fstream (http://www.cplusplus.com/ref/iostream/fstream/) et pour les gzip gzipstream (un stream dérivé de fstream utilisant la lib gzip) -- sur tes conseils au passage (topics/85079-simplification
SEEK_SET et autres sont remplacés par ios_base::beg,ios_base::cur et ios_base::end. le gzipstream n'accepte que ios_base::beg

Les fichiers que j'utilise peuvent être très gros.
En plus le fichier est indexé c'est à dire qu'en début il y a la position de l'info relative au début du fichier. Donc pour lire une info je pointe sur l'index (premier déplacement), je lis l'index, je m'y déplace (le 2ième), je lis la taille que fait l'info et je lis l'info dans de la mémoire allouée.
Cela est fait de très nombreuses fois!

Bon bah tant pis pour ces fonctions sur BZIP2, je vais faire sans.
Merci quand même

Zephyr> pourquoi immonde ? C'est un simple tableau de pointeurs à garder, sauf que au lieu d'être des void * ce sont des fpos_t.
Pollux> l'exemple de bob ?
Quant aux systèmes, c'est pas parce que on est habitués à glibc qu'il n'y a que celle là. Et la pratique d'utiliser un handle permet de contourner la limitation à 32 bits pour des fichiers qui sont plus gros. Là où il ne sera pas possible d'utiliser ftell/fseek avec un offset, un handle passera parfaitement.
En connaitre, non tu sais les deux seuls systèmes disposant d'une libc avec lesquels j'ai développé sérieusement en C c'est debian et msvc6. Les autres systèmes n'avaient pas de notion de fichiers, ou alors des fichiers structurés (pas possible à identifier comme des flux, donc pas de fread/fwrite/etc exposé).

uh là je ne suis pas tout à fait d'accord. Il est tout a fait possible de se déplacer dans un fichier gzip comme dans un fichier non compressé. Et la doc de gzip propose des fonctions (gz_seek et gz_tell) qui n'ont aucune mention "déconseillé". fgetpos et fsetpos n'existent pas dans l'API à ma connaissance.
Les fichiers que j'utilise peuvent être très gros.

Le passage sur fgetpos et fsetpos n'avait plus rien à voir avec zlib. Pour revenir à gzlib, non, c'est pas écrit déconseillé. C'est écrit :

If the file is opened for reading, this function is emulated but can be extremely slow.

Traduction : la bibliothèque revient au tout début du fichier, et redécompresse tout jusqu'au point que tu as demandé. Les fichiers que tu utilises peuvent être très gros tu as dit. A toi de voir.
Si tu fais un gzseek() pour aller à la fin d'un fichier de 600Mo, tu te tappes la décompression de 600Mo.
Si tu le fais 10 fois de manière non séquentielle, tu te tappes la décompression de 6Go pour rien.

M'enfin, non c'est pas *marqué* déconseillé. Tu fais comme tu veux.

spectras
: Zephyr> pourquoi immonde ? C'est un simple tableau de pointeurs à garder, sauf que au lieu d'être des void * ce sont des fpos_t.

Non non, je ne parle pas de la sauvegarde des positions au final (encore que, dans le cas de structures imbriquées un peu compliquées...), mais de la tronche du code que tu vas devoir te taper et qui va aller lire la totalité d'un fichier potentiellement énorme là où n'importe quel programmeur écrira des "fseek" permettant de sauter directement à la poigné d'offsets utiles pour un résultat beaucoup plus efficace... (quand "être portable" implique d'écrire des trucs attroces alors que tous les vrais systèmes ont une solution commune bien plus propre, bah c'est vite vu amha)

Ben en général tu t'amuses pas à stocker des trucs sans aucun rapport dans un même gros fichier, donc tu as souvent besoin de presque tout, et en lire la totalité n'est pas un problème.
Par ailleurs, ne pas utiliser de seek permet de lire le fichier indiféremment depuis un tube/socket/entrée standard.
Il existe également des périphériques qui ne supportent tout simplement pas l'opération "seek" (les lecteurs de bande par exemple).

object and these routines may be the only way to portably reposition a text stream.

Sinon, en passant juste pour indiquer que je l'ai pas inventé, la page man de fseek indique :     On some (non-UNIX) systems an ``fpos_t'' object may be a complex
 

Ca fait quand même tout un paquet de raisons pour lesquels il est préférable de ne pas utiliser de repositionnement en général, et fseek en particulier. A moins de ne viser qu'un système ou ensemble de systèmes bien connus, et couper court à toute utilisation autre que celle prévue initiallement.

spectras
: Ben en général tu t'amuses pas à stocker des trucs sans aucun rapport dans un même gros fichier, donc tu as souvent besoin de presque tout, et en lire la totalité n'est pas un problème.

Heu si, cf l'exemple que j'ai cité plus haut : un fichier contenant les animations d'un perso (obligatoirement sous forme d'un fichier et non pas d'une multitude de petits, pour pouvoir par exemple éviter de stocker plusieurs fois des frames redondantes, ou carrément des débuts/fins d'animations communs), mais dans lequel tu n'as évidemment pas besoin de lire tout le contenu pour chaque scène.

Par ailleurs, ne pas utiliser de seek permet de lire le fichier indiféremment depuis un tube/socket/entrée standard.

Quel intérêt dans l'exemple ci-dessus ? Ça n'aurait pas beaucoup de sens de remplacer ce fichier par un tube... et puisque c'est un fichier, on peut profiter de choses qui ne sont pas disponibles ailleurs.

Sinon, en passant juste pour indiquer que je l'ai pas inventé, la page man de fseek indique : [...]

La question n'est pas de savoir si tu as inventé ça ou non, c'est juste qu'ils sont bien gentils mais y'a des fois où suivre leurs conseils donnerait un très mauvais résultat.

Un truc qui me chiffone, c'est que seek_end n'est pas garanti pour les fichiers binaires.
Alors qu'une façon dite portable souvent utilisée pour connaître la taille d'un fichier est justement fseek(SEEK_END), ftell()...

Ben déjà cette méthode ne marchera pas avec un fichier >2Go.

Heu si, cf l'exemple que j'ai cité plus haut : un fichier contenant les animations d'un perso (obligatoirement sous forme d'un fichier et non pas d'une multitude de petits, pour pouvoir par exemple éviter de stocker plusieurs fois des frames redondantes, ou carrément des débuts/fins d'animations communs), mais dans lequel tu n'as évidemment pas besoin de lire tout le contenu pour chaque scène.

Sauf que c'est un cas spécifique. Tu te moques royalement de la portabilité sur un maximum de systèmes, et tu peux te permettre bien plus de choses du coup.
(en plus éviter de stocker plusieurs fois des frames redondantes, pas besoin de fseek, fsetpos suffit)

Quel intérêt dans l'exemple ci-dessus ? Ça n'aurait pas beaucoup de sens de remplacer ce fichier par un tube... et puisque c'est un fichier, on peut profiter de choses qui ne sont pas disponibles ailleurs.

Comme je disais, c'est un exemple spécifique où tu imposes une certaine quantité de restrictions. Ce qui est acceptable sur un programme à usage spécifique ne le sera pas forcément sur un programme générique. Par exemple un encodeur mp3 qui utilise fseek, là oui l'intérêt à ce qu'il utilise une façon orientée flux d'accéder à ses données est très intéressant, même s'il doit se passer du confort de fseek pour ça.

La question n'est pas de savoir si tu as inventé ça ou non, c'est juste qu'ils sont bien gentils mais y'a des fois où suivre leurs conseils donnerait un très mauvais résultat.

C'est plus des avertissements que des conseils : "attention, dans le cas général vous allez dans le mur. Mais si vous savez ce que vous faites y'a pas de problème".

spectras
: Ben déjà cette méthode ne marchera pas avec un fichier >2Go.

Tu as déjà donné cet argument, et il t'a déjà été répondu qu'on connait à l'avance la taille du fichier.

Sauf que c'est un cas spécifique. Tu te moques royalement de la portabilité sur un maximum de systèmes, et tu peux te permettre bien plus de choses du coup.

Sauf que la moitié des utilisations de fread/fwrite et cie que je fais sont des "cas spécifiques" on dirait... et ça ne rend pas fsetpos/fgetpos plus pratiques pour autant ^^

Comme je disais, c'est un exemple spécifique où tu imposes une certaine quantité de restrictions.

Bah j'impose que ce soit un gros fichier binaire structuré, ça me semble pas si particulier comme utilisation franchement... et dans le cas d'un fichier binaire, le considérer comme un flux n'est pas pour moi d'une logique à toute épreuve (oui, pourquoi pas, mais on peut aussi voir le fichier binaire comme un gros tableau d'octets dans lequel on veut avoir un accès aléatoire).

C'est plus des avertissements que des conseils : "attention, dans le cas général vous allez dans le mur. Mais si vous savez ce que vous faites y'a pas de problème".

Je ne vois pas exactement les proportions comme toi en fait. Ça ne me dérange pas d'utiliser fsetpos et fgetpos si un jour j'ai besoin de lire un fichier texte, petit et séquentiel, mais c'est quelque chose qui ne m'arrive quasiment jamais :/

OK donc le mieux finalement c'est de faire un peu comme le format ODF, c'est à dire stocker ses données dans plusieurs petits fichiers que l'on groupe et compresse via les couples TAR/GZIP ou TAR/BZIP2. On relit ensuite les données en décompressant le fichier qui nous intéresse dans un répertoire temporaire. Là le problème problème de la relecture d'un fichier compressé ne se pose plus et on peut éviter d'avoir un répertoire temporaire énorme. Je peut aussi utiliser fgetpos et fsetpos au lieu de fseek et ftell.

Oui, ou alors il faut que tu utilises un format de compression qui permet d'extraire des données indépendamment les unes des autres. Entre autres possibilités, tu as : le zip, ou le gzip/tar (faire un tar avec plein de fichiers compressés plutôt que l'inverse...ça compresse un peu moins bien, mais ça permet d'accéder directement au fichier voulu...par contre tu ne peux pas utiliser gzread et compagnie, tu seras obligé de travailler au Inflate).

Tu as déjà donné cet argument, et il t'a déjà été répondu qu'on connait à l'avance la taille du fichier.

Oui, sauf que ça tu l'as inventé. Et en l'occurence je répondais à Link, et vu qu'il utilise ça pour lire la taille du fichier je doute qu'il la connaisse à l'avance...

Sauf que la moitié des utilisations de fread/fwrite et cie que je fais sont des "cas spécifiques" on dirait... et ça ne rend pas fsetpos/fgetpos plus pratiques pour autant ^^

L'exemple que tu donnais supposait déjà un système assez complexe (capable de faire du rendu 3d). Tu exclue par ce biais énormément de systèmes, donc oui c'est spécifique. Et dans ce cas pas de problème.

Bah j'impose que ce soit un gros fichier binaire structuré, ça me semble pas si particulier comme utilisation franchement... et dans le cas d'un fichier binaire, le considérer comme un flux n'est pas pour moi d'une logique à toute épreuve (oui, pourquoi pas, mais on peut aussi voir le fichier binaire comme un gros tableau d'octets dans lequel on veut avoir un accès aléatoire).

Je parlais de la qualité du code du programme. D'ailleurs la phrase qui suit celle que tu as citée rend la cible de ce paragraphe évidente.

Je ne vois pas exactement les proportions comme toi en fait. Ça ne me dérange pas d'utiliser fsetpos et fgetpos si un jour j'ai besoin de lire un fichier texte, petit et séquentiel, mais c'est quelque chose qui ne m'arrive quasiment jamais :/

Ben ce sont des fonctions conçues au contraire pour un accès structuré. Tu te mets un marque-page pour pouvoir revenir plus tard à la structure qui t'intéresse (même si ça marche avec des fichiers textes, il est rare d'avoir des fichiers texte énormes au point de ne pas se contenter de tout charger en mémoire et traiter après).

Et sinon, le problème de spomky est intéressant. Supposons qu'un jour tu veuilles compresser ton très gros fichier (bah oui s'il est si gros que ça il prend de la place pour rien), ben si tu as implémenté sa lecture avec des fseek / ftell, tu vas avoir quelques soucis en passant à gzseek et gztell.

spectras
: Et en l'occurence je répondais à Link, et vu qu'il utilise ça pour lire la taille du fichier je doute qu'il la connaisse à l'avance...

Ah ok. Dans mon cas je connais la taille du fichier ^^

L'exemple que tu donnais supposait déjà un système assez complexe (capable de faire du rendu 3d). Tu exclue par ce biais énormément de systèmes, donc oui c'est spécifique. Et dans ce cas pas de problème.

On pourrait titiller en trouvant des exemples de fichiers binaires complexes traités par une simple application en console, mais admettons que dans la majorité des cas le problème ne se pose pas ^^

Je parlais de la qualité du code du programme. D'ailleurs la phrase qui suit celle que tu as citée rend la cible de ce paragraphe évidente.

Pas compris ce que tu voulais dire alors.

Et sinon, le problème de spomky est intéressant. Supposons qu'un jour tu veuilles compresser ton très gros fichier (bah oui s'il est si gros que ça il prend de la place pour rien), ben si tu as implémenté sa lecture avec des fseek / ftell, tu vas avoir quelques soucis en passant à gzseek et gztell.

Non, je prendrai une solution qui permette de sauter directement à des offsets contenus dans mon fichier : il est absolument hors de question que je décompresse la totalité du fichier pour n'en lire que la moitié, si il est si gros que ça :/

On pourrait titiller en trouvant des exemples de fichiers binaires complexes traités par une simple application en console, mais admettons que dans la majorité des cas le problème ne se pose pas ^^

J'avoue ne pas avoir d'exemple. Des fichiers binaires de taille importante traités par des programmes ayant vocation à ne pas dépendre du système... je vois bien les iso de cd et dvd, mais mkisofs et cdrecord les écrivent et les lisent séquentiellement donc c'est un mauvais exemple. Les vidéos...mais tous les lecteurs *nix que je connais sont capables de lire une vidéo depuis un pipe, donc ce n'est pas un bon exemple non plus. Non je ne vois pas, il faudrait essayer de compiler un noyal avec une trace sur l'appel système seek.

Pas compris ce que tu voulais dire alors.

spectras>

Quel intérêt dans l'exemple ci-dessus ? Ça n'aurait pas beaucoup de sens de remplacer ce fichier par un tube... et puisque c'est un fichier, on peut profiter de choses qui ne sont pas disponibles ailleurs.

Comme je disais, c'est un exemple spécifique où tu imposes une certaine quantité de restrictions. Ce qui est acceptable sur un programme à usage spécifique ne le sera pas forcément sur un programme générique. Par exemple un encodeur mp3 qui utilise fseek, là oui l'intérêt à ce qu'il utilise une façon orientée flux d'accéder à ses données est très intéressant, même s'il doit se passer du confort de fseek pour ça.

Je veux dire que tu te restreins à la lecture de ta donnée depuis un fichier. Ca peut être acceptable sur un programme à usage spécifique, mais pas forcément sur un programme à usage générique (voir l'exemple dans ma citation de moi-même).

Ou autre exemple : si cdrecord utilisait fseek pour parcourir les tables des images iso, il ne serait pas possible de graver sans passer par un fichier temporaire.

spectras :
]Je veux dire que tu te restreins à la lecture de ta donnée depuis un fichier. Ca peut être acceptable sur un programme à usage spécifique, mais pas forcément sur un programme à usage générique (voir l'exemple dans ma citation de moi-même).
Ou autre exemple : si cdrecord utilisait fseek pour parcourir les tables des images iso, il ne serait pas possible de graver sans passer par un fichier temporaire.

Ah, ok. Mais effectivement, il me semblait assez normal de considérer qu'un programme qui lit des fichiers n'est et ne sera souvent pas destiné à travailler avec d'autres sources. Comme j'ai du déjà le poster (flemme de remonter ^^), la comparaison fichier <> flux n'est pas si évidente que ça pour moi; certains fichiers bien spécifiques peuvent effectivement être considérés comme des flux et traités comme tels, mais il y a trop de variations pour pouvoir prendre ça comme le cas géneral amha.

spectras
:

On pourrait titiller en trouvant des exemples de fichiers binaires complexes traités par une simple application en console, mais admettons que dans la majorité des cas le problème ne se pose pas ^^

J'avoue ne pas avoir d'exemple. Des fichiers binaires de taille importante traités par des programmes ayant vocation à ne pas dépendre du système... je vois bien les iso de cd et dvd, mais mkisofs et cdrecord les écrivent et les lisent séquentiellement donc c'est un mauvais exemple. Les vidéos...mais tous les lecteurs *nix que je connais sont capables de lire une vidéo depuis un pipe, donc ce n'est pas un bon exemple non plus. Non je ne vois pas, il faudrait essayer de compiler un noyal avec une trace sur l'appel système seek.

C'est pas les exemples qui manquent, pourtant : lecture d'un fichier spécifique dans une iso (ou dans une archive non-solide style tar/zip/rar), p2p (l'accès aléatoire est indispensable), et je ne parle même pas des applications plus spécifiques (moteur de recherche, bioinformatique...)
Pour les vidéos c'est pas parce qu'ils sont "capables" de lire une vidéo depuis un pipe que s'ils ont un fichier ils peuvent pas seeker à un endroit arbitraire (ou alors quand t'as loupé un passage tu peux pas revenir en arrière, super )

Bref, tout ce qui peut prendre de la place sur un disque dur sans être un backup purement séquentiel ou une floppée de fichiers minuscules risque de faire appel à fseek ^^

Et y a des versions 64-bits de fseek, hein (fseeko64 et/ou fseek64)

Sans compter que meme sans faire du rembobinage (qui est impossible sur un flux) fseek permet aussi d'avancer par rapport au point courant, ce qui par contre est possible avec un flux. (exemple, on veux ignorer les 42 octets suivants)