Discussion :

[Flynet]

Bonjour,

La fonction ftell qui permet de stocker l'offset du curseur peut être utilisé pour récupérer la taille d'un fichier. J'aimerai savoir comment peut-on récupérer cette taille si elle est de l'ordre du go? La fonction ftell renvoie elle même un long donc pas assez pour donner l'offset de gros fichier. Je sais qu'il existe la fonction FileAttributesEx des api windows mais j'aimerai le faire de manière portable.

Ma deuxième question concerne telldir, celle-ci renvoie off_t octets. Mais dans quelle genre de variable stocker ce résultat lorsqu'il dépasse un int ou un long ? (Plusieurs Go)

[uriotcea]

Salut,

Il a une version 64 bits des fonctions que tu evoques permettant de lire des fichier de plus de 4Go
- ftello64
- fopen64
- fseeko64

Pour les utiliser sur un systeme 32 bits if faut definir les variables suivantes

_LARGEFILE64_SOURCE
__USE_FILE_OFFSET64
#define _FILE_OFFSET_BITS 64

[Flynet]

Bonjour,

Ces fonctions ne sont pas référencés dans le man que ce soit sur linux ou sur le net. Est-ce normal ? Et est-ce qu'elles sont standards pour les systêmes 32bits?

Ensuite je connaissais le #define _FILE_OFFSET_BITS 64 qui me permettait d'ouvrir de gros fichiers avec fopen. Mais je ne vois pas comment définir les variables dont tu parles. Est-ce que tu peux me donner un exemple ?

Ensuite, ma question initiale c'était dans quel type de variables stocker le nombre renvoyé par les fonctions quand la taille fait plusieurs go donc, est supérieure à ce que peut stocker un int ?

[uriotcea]

Oui j'avais compris ta demande, mais pour stocker des variable superieur à 2Go il faut déjà etre en mesure de les obtenir. Et les la fonction ftell classique, par example, ne permet pas d'obtenir de telles valeurs. D'ou l'utlisation de fonction étendues au 64bits.
Maintenant pour stocker des entiers > 2Go tu as plusieurs solutions équivalentes.
- long long in
- off64_t

Pour la directive "#define _FILE_OFFSET_BITS 64", je pense qu"elle seule suffit dailleurs, il suffit de la mettre au debut de ton fichier cpp ou mieux de ton fichier d'include. Elle est nécessaire si tu compiles 32 bits, sinon pas besoin de l'inclure je pense.

[Flynet]

Ah oui je comprends. Cependant je ne trouve aucun prototype de ces fonctions. Sais-tu où je pourrai les trouver ?

Est-ce qu'elles s'utilisent de la même manière que les versions 32 bits ?
Car gcc me renvoie :assigment makes pointer from integrer without a cast

et apparament ça concerne la ligne de mon fopen :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fichier = fopen64("image.iso", "rb");

[uriotcea]

De mémoire je crois qu'il ne faut pas etre en 'ansi strict', parce qu'il n'y a pas de prototype, quelquechose comme ca.
Sinon tu fais un google sur fopen64 et tu auras des tas d'example.

[Flynet]

Je ne pense pas que cela soit le programme car d'après ce lien : http://cactuscode.org/pipermail/deve...ry/005700.html
Depuis la version 9, le strict ansi n'est plus défini. Et même quand je modifie les options de compilation j'ai toujours ce warning et j'obtiens un 0 pour la taille. Voici mon code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#define _FILE_OFFSET_BITS 64
#include <stdio.h>
#include <stdlib.h>
 
int main(int argc, char *argv[])
{
FILE *fichier = NULL;
long long int taille = 0;
 
fichier = fopen64("file.iso", "rb"); // warning: assignment makes pointer from integer without a cast
 
if (fichier != NULL)
{
fseeko64(fichier, 0, SEEK_END);
taille = ftello64(fichier);
printf("%lld\n", taille);
fclose(fichier);
}
 
return 0;
}

[uriotcea]

Bon j'ai essayé ton code sans changer une virgure, à part le nom du fichier et pas de souci pour moi, il fonctionne sur un code 32bits sur un fichier > 4Go.
Je l'ai également testé sous linux, ton systéme visiblement, et là aussi ca fonctionne.
J'utilise gcc4.5 peut-etre est-ce ton compilo le probléme.

[diogene]

warning: assignment makes pointer from integer without a cast

semble indiquer que le prototype de fopen64() n'a pas été trouvé.

Pour information :

12.3 Opening Streams
....
— Function: FILE * fopen64 (const char *filename, const char *opentype)

This function is similar to fopen but the stream it returns a pointer for is opened using open64. Therefore this stream can be used even on files larger then 2^31 bytes on 32 bit machines.

Please note that the return type is still FILE *. There is no special FILE type for the LFS interface.

If the sources are compiled with _FILE_OFFSET_BITS == 64 on a 32 bits machine this function is available under the name fopen and so transparently replaces the old interface

[Flynet]

Merci pour la référence, en fait ftello64, fopen64, fseeko64 restent fopen, ftello et fseeko avec le #define FILE_OFFSET_BITS 64

Mon code marche, je parviens à récupérer les tailles de gros fichiers. Merci de votre aide

[uriotcea]

Super, mais pourquoi donc l'example que tu nous a fournit ne fonctionnait pas, alors?

[Flynet]

Ce qui est déjà sur c'est que lorqu'on utilise le define, il faut remplacer ces fonctions par fopen, ftello et fseeko comme l'indique la référence donnée par diogene.
Ensuite j'ai essayé de les utiliser sans la constante, mais elles marchent pas. Toujours le même warning. Peut être que ces fonctions ont été elevées ? Mais je ne comprends pas comment elles marchent chez toi...
J'ai installé gcc récemment donc je pense pas que ce soit un problème de version. Peut-être les options du compilo ?

[uriotcea]

C'est effectivement étrange, d'autant plus que je fais ca sous Windows, plusieurs linux et même MacOS avec des versions de gcc différentes donc.

[Flynet]

J'ai testé sous windows avec la dernière version de code::blocks qui utilise gcc et là c'est l'inverse. Déjà, il ne connait les fonction ftello et fseeko et je dois utiliser ftello64 et fseeko64 à la place. Par contre pas de problème entre fopen et fopen64 les 2 marchent.

[uriotcea]

Ok comme moi donc. J'utilise aussi code::block dans tous mes OS, mais je ne pense pas que l'EDI change quelquechose à l'affaire