Taille limite : 4 Go ?

Bonjour,
tout d'abord merci pour ce très pratique éditeur de texte.
Pour ma part, je l'utilise pour visualiser des bases de données au format TXT, et vérifier ainsi le contenu de la première ligne et le nombre de lignes.
Malheureusement, il semblerait que 4 Go soit une taille critique pour GBEPAD...
Le fichier que j'ouvre ne se découpe pas à l'affichage par paquet de 10000 lignes comme d'habitude, mais s'ouvre en une fois et ne comporte au total que 46978 lignes (au lieu de 23 millions).
Confirmez-vous que 4 Go constitue la taille limite de votre précieux outil ?

Bonjour,

A titre personnel, j'ai pu ouvrir un fichier de 8 Go avec GBEPad. Toutefois, la zone d'édition de texte est limitée effectivement à 4 Go. C'est pour cela que pour les fichiers volumineux, GBEPad découpe le fichier d'origine en plein de petits fichiers et affiche dans la zone d'édition qu'un seul petit fichier à la fois.

Il est possible dans les options de configuration de GBEPad d'indiquer à partir de quelle taille il doit considérer un fichier comme étant "volumineux" (par défaut c'est 100 Mo)et en combien de lignes il doit scinder le fichier pour pouvoir le lire (par défaut c'est 10 000 lignes).

Le principe de fonctionnement est le suivant : à l'ouverture d'un fichier, GBEPad contrôle sa taille. Si la taille est supérieure à la taille paramétrée (100 Mo par défaut) alors GBEPad va découper le fichier d'origine en n fichiers de 10 000 lignes maximum (10 000 étant la valeur par défaut). Il se peut qu'un fichier de 10 000 lignes fasse plus de 4 Go : cela dépend du nombre de caractères par ligne (GBEPad version 5.x travaille en interne en ASCII donc 1 caractère = 1 octet, la version 6 en cours de développement sera en nativement en unicode).

Vous pouvez modifier le paramétrage de GBEPad en fonction de votre fichier : si votre fichier contient un grand nombre de caractères par ligne diminuer le paramètre du nombre de lignes. En le passant à 1 000 (voir 100), GBEPad devrait pouvoir ouvrir votre fichier.

Attention cependant : en diminuant le nombre de lignes pour les fichiers éclatés, cela signifie qu'il y aura plus de "petits" fichiers donc plus d'accès disque. Le découpage du fichier d'origine prendra donc plus de temps.
Il faudra s'armer de patience lors de l'ouverture du fichier...

Autre piste possible, dans les options de GBEPad, vous pouvez configurer le répertoire dans lequel GBEPad va générer les fichiers découpés. Il faut veiller à ce que le disque sur lequel pointe ce répertoire dispose de la place nécessaire (par défaut ce répertoire est le sous répertoire temp du répertoire où est installé GBEPad.exe).

Cordialement,
Grégory.

Bonjour,
merci pour cette réponse rapide.
Malheureusement, malgré vos conseils, le problème n'est pas résolu...
Si cela vous intéresse, je vous invite à faire l'essai de votre côté sur le fichier en cause, disponible à l'adresse suivante :
recensement-2008.insee.fr/telechargement/fichiers-detail/FD_LOGEMT_2008.zip

Cordialement,
JBM

Bonjour,

J'ai récupéré le fichier zip. Avec l'outil 7-zip, je n'arrive pas à le décompresser (erreur CRC), avec WinRar, il ne dézippe que les premiers 8 Mo (et en ouvrant le résultat dans GBEPad, il y a effectivement 46978 lignes) enfin, j'ai essayé également avec Winzip et là il décompresse 4 Go mais s'arrête en indiquant que cela ne correspond pas à la taille du fichier non compressé inscrite dans le zip (8828715).

En y regardant de plus prêt avec 7-zip, on voit que l'OS hôte est fat. Je ne sais pas sur quelle machine a été fait le zip, mais il semblerait qu'il ait été fait sur un disque formaté en FAT, or en FAT la limite est de 4Go. En NTFS (pour Windows) la limite est plus grande.
7-Zip et Winzip génèrent une erreur, WinRar ne signale rien mais n'extrait que les 8 828 715 premiers octets (=> GBEPad ne détecte pas un fichier volumineux).

La taille erronée inscrite dans le zip est certainement lié au fait qu'au delà des 4 Go, le compteur est reparti à zéro du fait de la fat...

Quelle est la taille du fichier indiquée par l'explorateur Windows sur votre poste ?

Cordialement,
Grégory.

Bonjour,
et encore merci pour le temps consacré.
J'ai essayé aussi avec izarc, sans succès (fichier de 8 622 Ko dans l'explorateur windows).
J'ai pu le décompresser avec Winzip 8.1 SR-2.
Le fichier fait 4 202 926 Ko dans l'explorateur Windows.
Mais à l'ouverture dans GBEPad je n'obtiens que 46 978 lignes, et d'un seul tenant, sans découpage.
Ce serait donc à cause du FAT que GBEPad ne détecte pas le fichier dans son entier ?
La lecture du fichier avec un programme SAS se passe bien a priori.

Cordialement,
JBM

Bonsoir,

Pour moi le problème vient du zip. La taille du fichier décompressé indiqué dans le zip est 8828715 octets (pratiquement 8 Mo). Les dézippeurs doivent créer l'enveloppe du fichier à 4Go (la limite de la fat) mais ne place dans le fichier que les 8 Mo indiqués dans le zip.
Je ne connais pas SAS mais c'est peut être une solution fonctionnant sous Unix ou sur des machines Windows capables de gérer du NTFS (à partir de Windows 2000 il me semble). Je ne pense pas que le fichier txt soit en cause : je pense que c'est lors de la compression en zip que cela à corrompu le fichier.

Cordialement,
Grégory.

merci beaucoup en tout cas de m'avoir consacré de votre temps !

Cordialement,
JBM