Почему sort.exe урезает большой вывод в 32-битной Windows?

Question

У нас есть файл данных от клиента размером 1,443,777,659 байт.

В отсортированном выводе отсутствуют строки, и его размер составляет всего 1 269 801 985 байт.

Пример команды: сортировка -k 1,10 -T. -s -i file_to_sort.txt -o out.txt

Мы пробовали на 32-битных системах Win 7 и XP.

Мы попробовали прилагаемый sort.exe, который поставляется с Windows, а также двоичные файлы от UnxUtils и Gnu coreutils.

Ни один из них не дает ошибки, однако все приводят к одинаковому размеру вывода Я попробовал другую бесплатную утилиту, которая работает, но намного медленнее.

Я полагаю, что это может быть связано с 32-разрядным ограничением, однако размер файла, кажется, не соответствует ни одному из обычных подозреваемых, и эти программы работают, записывая и объединяя меньшие файлы, ни один из которых не достигает размера 2 ГБ.

Любые советы о том, как добраться до сути этого? Благодарю.

Answer 1

Итак, проблема не была связана с размером файла вообще. Похоже, что файл открывается в текстовом режиме и в конце содержит символ 0x1A (^ Z или EOF в Windows).

Как только он попадает в этот символ во время ввода, он перестает читать. Обойти это невозможно, поскольку нет флага для открытия файла в двоичном виде.

Я должен был найти это быстрее, но это не так легко, чтобы копаться в файле 1,5 ГБ :)

Связанный запрос: https://stackoverflow.com/questions/13582804/why-can-windows-not-read-beyond-the-0x1a-eof-character-but-unix-can

Answer 2

Вы не хотите игнорировать непечатаемые символы, если файл содержит их. Удалите опцию -i и запустите с LC_ALL = C.

например

export LC_ALL=C
sort -k 1,10 -s <file_to_sort.txt >out.txt