При использовании getdents на ФС с длинным inode (например, на glusterfs), получаем ошибку getdents(4, 0x8fcce68, 32768) = -1 EOVERFLOW (Value too large for defined data type) Описание причины здесь: http://bugs.etersoft.ru/show_bug.cgi?id=9649#c1, но оно неадекватно: > Но так как смонтированная директория создана на 64битной машине Не имеет значения где что создано. Нам важно, с чем мы работаем, а не в какой стране это произведено. > а clamscan запускался на 64битной cellar, на 32-битной > то возникала ошибка переполнения результирующего буфера. допустим. > Планируется решить укорачиванием получаемой структуры dirent, если не вмещается в ее 32битную версию. Структуру ну никаким образом нельзя укоротить. А проблема там может быть только всё та же — есть код проверки длины числа в поле inode, и если оно не влезает, формируется ошибка EOVERFLOW. В общем, это всё та же тема, естественно, что и в http://bugs.etersoft.ru/show_bug.cgi?id=9552
Внесены изменения в функции, отвечающей за возврат inode для директорий. git.eter:/people/reprofy/packages/glibc.git. новая версия glibc теперь не возвращает ошибку, когда у запрашиваемой директории inode занимает более 32х бит, а возвращает нулевой inode. Ядро опробовано, работает. Тестом служила ручная подстановка в функцию stat названия папки Исправлено только сейчас, потому что раньше директории не проверялись,а тестом служила также ручная проверка.
Откладываю, решение пока не интересно.
