Pourquoi sort.exe tronque-t-il les sorties volumineuses sur Windows 32 bits?

2

Nous avons un fichier de données d’un client d’une taille de 1 443 777 659 octets.

La sortie triée a des lignes manquantes et sa taille est seulement de 1 269 801 985 octets.

Exemple de commande: sort -k 1,10 -T. -s -i file_to_sort.txt -o out.txt

Nous avons essayé des systèmes Win 7 et XP 32 bits.

Nous avons essayé le fichier sort.exe fourni avec Windows, ainsi que les fichiers binaires d'UnxUtils et de Gnu coreutils.

Aucun ne donne une erreur, mais tous ont exactement la même taille de sortie. J'ai essayé un autre utilitaire gratuit qui fonctionne mais est beaucoup plus lent.

Je pense que cela est peut-être dû à une limitation de 32 bits. Toutefois, la taille du fichier ne semble pas proche des suspects habituels et ces programmes fonctionnent en écrivant et en fusionnant des fichiers plus petits, dont aucun ne dépasse les 2 Go.

Des conseils sur la façon d'aller au fond des choses? Merci.

windows 32-bit sorting gnu Nick P
la source
La meilleure façon de vérifier s'il s'agit d'un problème 32 bits 64 bits consiste à l'essayer sur un système d'exploitation 64 bits. Assurez-vous d'utiliser un outil 64 bits, sinon cela n'aura pas d'importance.
Ramhound

Réponses:

1

OK, le problème n'était donc pas du tout lié à la taille du fichier. Il semble que le fichier soit ouvert en mode texte et qu'il contienne un caractère 0x1A (^ Z ou EOF sous Windows) vers la fin.

Une fois que ce caractère a été touché lors de la saisie, il arrête de lire. Il n'y a aucun moyen de contourner cela car il n'y a pas d'indicateur pour ouvrir le fichier en tant que binaire.

J'aurais dû trouver cela plus rapidement, mais ce n'est pas si facile de creuser un fichier de 1,5 Go :)

Requête associée: https://stackoverflow.com/questions/13582804/why-can-windows-not-read-beyond-the-0x1a-eof-character-but-unix-can

Nick P
la source
0

Vous ne voulez pas ignorer les caractères non imprimables si le fichier les contient. Supprimez l'option -i et exécutez-la avec LC_ALL = C.

par exemple. 

export LC_ALL=C
sort -k 1,10 -s <file_to_sort.txt >out.txt
Ярослав Рахматуллин
la source
Nous ajoutons les clés de tri dans un processus précédent, nous pouvons donc garantir qu’il s’agit bien de caractères imprimables. J'ai essayé cette commande quand même mais j'ai eu le même résultat - nous sommes sur Windows mais je viens de faire "set LC_ALL = C" en supposant que ce sera la même chose.
Nick P
Je ne sais pas si Windows utilise les variables d'environnement LC_ *. Mais ça supporte sort /locale=C.
grawity
Oui, j'ai aussi essayé, nous devrions l'utiliser. Mais la question n'est pas l'ordre de tri. C'est que des lignes entières sont manquantes dans la sortie, soit plus de 10% du fichier.
Nick P