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.En fait c'est parce que tu conçois ton fichier comme plein de données distinctes accolées. Ce n'est pas dans la philosophie unix de l'analogie aux flux, donc ça s'y prête mal. Ce n'a tout simplement pas été prévu pour.
Godzil :Je sais pas pour fseek, mais en tous cas lseek ne le permet pas. (cela dit pour fseek ça me semble peu probable qu'ils se soient amusés à implémenter une émulation, à voir ?)
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)
spectras :
Ben : - la lecture d'un fichier spécifique dans une iso, c'est du ressort du noyau (loop)
- pour les archives, le tar est un mauvais exemple car presque tout le temps recompressé, mais les deux autres pourquoi pas. Cela dit c'est tout de même un usage peu courant (tu extrais souvent un fichier unique d'une archive de taille importante ?).
Pour les vidéos, ça va dans mon sens. Oui ils sont capables de tirer parti de la fonctionnalité si elle est présente, mais non ils n'en dépendent pas. La meilleure des options ^^
Oui, mais les versions 64 bits sont une extension très peu répandue, et qui présentent le même problème, ne faisant que le repousser 32 bits plus loin (je ne les ai croisés que sur glibc pour l'instant).
En fait c'est parce que tu conçois ton fichier comme plein de données distinctes accolées. Ce n'est pas dans la philosophie unix de l'analogie aux flux, donc ça s'y prête mal. Ce n'a tout simplement pas été prévu pour.
En suivant les principes unix, tes données vont être sérialisées indépendamment, faisant un flux par entité indépendante. Dès lors, la question d'accéder au milieu des données n'a plus de sens.
Zephyr
: erf... et moi qui considère comme particulièrement propre les solutions comme celles de quake/doom où toutes les données du jeu (sons, textures, modèles, maps...) sont enregistrées dans un énorme fichier, permettant d'installer/désinstaller des addons et mods très facilement (un fichier à copier/supprimer)...
je prefere 1000x UT a Quake, mais alors de ce coté Quake c'est vraiment le must (et UT une vrai horreur..)je vois pas de raison (autre qu'historique) pour que monter une iso soit fondamentalement différent de monter un tar/zip/rar, mais bon ^^La complexité. Mais effectivement j'ai failli évoquer les translateurs du Hurd pour les zip, puis je me suis dit que c'était pas le topic pour parler de ça
ben oui, c'est un usage courant, en tout cas pour les OS où on n'utilise pas uniquement du tar.gz/tar.bz2...Ah oui ? J'ai jamais fait. Perso un .zip c'est toujours bouton droit => extraire (que ce soit sous windows ou kde).
Ben je dis pas le contraire (de toute façon on peut toujours émuler fseek avec rewind+fread ^^), mais ça veut pas dire que fseek est pas indispensable quand même...Vrai (encore que rewind sur un pipe tu vas avoir quelques soucis). Mais c'est dans l'autre sens : la question était de faire un programme qui sait s'en passer. Evidemment, un développeur de libc doit la mettre dedans pour des raisons de compatibilité. A ce sujet, j'ai toujours trouvé l'intro de la RFC sur le TCP très bien là dessus : "be conservative in what you do, be liberal in what you accept from others."
Ca ne repousse pas le problème 32 bits plus loin : tu peux utiliser fseeko() et avec un #define tu peux changer la taille de off_t (potentiellement 128 bits le jour où ça sera nécessaire)D'une part, sur certains systèmes changer ce #define nécessite de recompiler tout le système (c'est le cas de OpenBSD par exemple). D'autre part, quelle que soit la valeur, même 256 bits, ça n'est que repousser la limite, mais elle est toujours là. Loin ? Oui, mais quand on a mis celle à 32 bits elle paraissait démesurée aussi.
Tu crois sérieusement que ce serait réaliste de transformer les mp3 en 20000 fichiers distincts, ou les films en deux répertoires de 200000 fichiers chacun !?Ce n'est absolument pas ce que j'ai dit, d'ailleurs si tu remontes 2/3 posts plus haut je donne l'exemple d'une vidéo comme un flux de données unique (et qui se lit très bien séquentiellement, d'ailleurs). Idem pour un mp3.
erf... et moi qui considère comme particulièrement propre les solutions comme celles de quake/doom où toutes les données du jeu (sons, textures, modèles, maps...) sont enregistrées dans un énorme fichier, permettant d'installer/désinstaller des addons et mods très facilement (un fichier à copier/supprimer)... on a effectivement pas la même vision des chosesClairement pas en effet. Et l'exemple est bien choisi. Pour moi un jeu qui se modde idéalement, un mod c'est un zip que tu décompresses dans le répertoire du jeu.
spectras
: D'une part, sur certains systèmes changer ce #define nécessite de recompiler tout le système (c'est le cas de OpenBSD par exemple). D'autre part, quelle que soit la valeur, même 256 bits, ça n'est que repousser la limite, mais elle est toujours là. Loin ? Oui, mais quand on a mis celle à 32 bits elle paraissait démesurée aussi.
Tu crois sérieusement que ce serait réaliste de transformer les mp3 en 20000 fichiers distincts, ou les films en deux répertoires de 200000 fichiers chacun !?Ce n'est absolument pas ce que j'ai dit, d'ailleurs si tu remontes 2/3 posts plus haut je donne l'exemple d'une vidéo comme un flux de données unique (et qui se lit très bien séquentiellement, d'ailleurs). Idem pour un mp3.
erf... et moi qui considère comme particulièrement propre les solutions comme celles de quake/doom où toutes les données du jeu (sons, textures, modèles, maps...) sont enregistrées dans un énorme fichier, permettant d'installer/désinstaller des addons et mods très facilement (un fichier à copier/supprimer)... on a effectivement pas la même vision des chosesClairement pas en effet. Et l'exemple est bien choisi. Pour moi un jeu qui se modde idéalement, un mod c'est un zip que tu décompresses dans le répertoire du jeu.
Par exemple, les addons de WoW fonctionnent comme ça : chaque addon crée un répertoire dans Interface\Addons, avec un ficher par boite de dialogue, un fichier par script et un fichier sommaire indiquant quoi charger.
Encore que la chose soit discutable, parce qu'un mod pourrait être considéré comme une unité de données, et donc être rassemblé en un unique fichier (qui, étant chargé intégralement, ne nécessite pas de seek, d'ailleurs).
Pollux :
Pour un usage "normal" un mp3 ou un film n'est pas un flux qui doit impérativement se lire du début jusqu'à la fin (comme pourrait l'être, je sais pas, une page html où on ne peut rien comprendre sans avoir *tout* lu depuis le début), c'est un flux où on doit pouvoir accéder aléatoirement à un endroit arbitraire (enfin pas tout à fait, puisque les codecs courants subdivisent le fichier en des tas de petits frames)
... Pour un usage "normal" un mp3 ou un film n'est pas un flux qui doit impérativement se lire du début jusqu'à la fin (comme pourrait l'être, je sais pas, une page html où on ne peut rien comprendre sans avoir *tout* lu depuis le début), c'est un flux où on doit pouvoir accéder aléatoirement à un endroit arbitraire (enfin pas tout à fait, puisque les codecs courants subdivisent le fichier en des tas de petits frames)Je suis perdu. C'est quoi le rapport avec la question ?
Il n'y a aucune raison pour qu'un mod de 3 Go ait besoin d'être chargé intégralement... Quel serait le problème si le mod était un tar/zip/iso ?La réponse à la question est très précisément ce que tu as cité. S'il n'a pas besoin d'être chargé intégralement, ce n'est pas une unité de données donc ça peut être séparé en plusieurs fichiers indépendants.
Godzil :
Autant dire que 2^256 est largement superieur au nombre d'atomes dans l'univers, et je crois que c'est pareil pour 2^128
(et puis c'est pas inconcevable qu'on puisse stocker un certain nb de bits par atome)
)
