Bug 9670

Summary: Исправить работу функции getdents на файловых системах с inode >2^32
Product: [Внутреннее (Etersoft)] Отдел серверных решений Reporter: Vitaly Lipatov <lav>
Component: ОбщееAssignee: Денис Обрезков <reprofy>
Status: DEFERRED --- QA Contact: Vitaly Lipatov <lav>
Severity: minor    
Priority: P4    
Version: не указана   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:
Заявки RT: Связано с:
Дата напоминания:
Bug Depends on:    
Bug Blocks: 9552    

Description Vitaly Lipatov 2013-11-15 13:57:26 MSK
При использовании 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
Comment 1 Денис Обрезков 2013-11-15 19:07:19 MSK
Внесены изменения в функции, отвечающей за возврат inode для директорий.
git.eter:/people/reprofy/packages/glibc.git. 
новая версия glibc теперь не возвращает ошибку, когда у запрашиваемой директории inode занимает более 32х бит, а возвращает нулевой inode. Ядро опробовано, работает. Тестом служила ручная подстановка в функцию stat названия папки Исправлено только сейчас, потому что раньше директории не проверялись,а тестом служила также ручная проверка.
Comment 2 Vitaly Lipatov 2017-10-28 18:44:22 MSK
Откладываю, решение пока не интересно.