On Wed, Jul 14, 2004 at 09:07:22AM +0300, Victor Cheburkin wrote:
Это неправильно скомпиленный апач. Вообще гофоря, не факт - ибо поведение того же wget при получении "большого числа" - не предсказуемо. И так при таскании такого оно писать отрицательный размер и скорость начинает ;). Думаю, с кучей другого софта были бы те же проблемы, и послать "unspecified length" вместо числа - лучшее решение. Это зависит от автора что он имел ввиду под MAX filelength.
Но всё-таки, чего ж логгинг валился нафиг (работающий прочесс по достижении 2Гб падал) - не ясно. Точно так же, думаю, что fopen() для логов делается обычно в append mode - то есть, тоже нигде не светится seek position, ну или fseek() "в конец файла" - тоже ничего "такого" не возвращает.
Просто вместо fopen нужно делать fopen64, вместо fseek -- fseek64 и т.д. Если проги скомпилить без нужных дефайнов (их там два), то эти вызовы использоваться не будут -- тот же struct FILE явно не заточен под 64-битные указатели, а обычный fseek позовет обычный lseek, а не lseek64.
При нормально написанных исходниках рассчитанных на largefile делать такого ненадо. Это сделают за тебя libc. При наличии defines: _LARGEFILE_SOURCE Some more functions for correct standard I/O. _LARGEFILE64_SOURCE Additional functionality from LFS for large files. _FILE_OFFSET_BITS=N Select default filesystem interface. эти же define включаются автоматом при наличии define _GNU_SOURCE или _XOPEN_SOURCE >= 500. -- With best regards, Alexandr Kanevskiy. ISP Inter-Don. CTO AK2240-RIPE, AK2-6BONE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message