[Gluster-devel] glusterfs_open() glusterfs_fstat() glusterfs_readdir() bug?

[Serial Thrilla]

Which system do you use?

I checked CentOS4, CentOS5, and CentOS5-x86_64 and all d_reclen members 
are "unsigned short int".

I think we may also have to be careful because there are d_reclen and 
d_namlen. It appears that d_reclen can be the size of the dirent struct 
or it can be the length of d_name depending if d_namlen exists or not.

I checked other systems (http://fxr.watson.org/) and it looked like most 
of them had a d_reclen of 16bits and I noticed one even had a d_namlen 
of 8 bits.

Thanks Shehjar!

Rob Olmos


Shehjar Tikoo wrote:
> Serial Thrilla wrote:
>> I was doing some investigation into the glusterfs_readdir() issue:
>>
>> On my system, dirent struct member "d_reclen" is an "unsigned short int"
>> but the _gf_dirent_t dirent struct "d_len" member is a uint32_t
>> (unsigned long int).
> 
> That seems to be an indicator of a problem because the second
> glfs.c test works fine on an empty directory on my system.
> 
> I'll be looking into this next week.
> 
> Thanks
> -Shehjar
> 
>>
>> libglusterfsclient.c line 2438 has:
>>
>> dirp->d_reclen = entry->d_len;
>>
>> It looks to me like that value is too big and possibly not storing the
>> correct record length. May also explain why the line before:
>>
>> /* dirp->d_type = entry->d_type; */
>>
>> is commented out because it was being overwritten by the d_reclen
>> assignment.
>>
>> Since this value is being stored incorrectly, line 2440 then uses the
>> reclen from dirent for the null byte. Might explain why I get a huge
>> reclen and only get one random character as the entry name.
>>
>> Attached is my system's dirent struct.
>>
>> Thanks!
>> Rob
>>
>>
>> Serial Thrilla wrote:
>>> Thanks! That patch fixes the glusterfs_fstat() call.
>>> Unfortunately, glusterfs_readdir() wasn't fixed.
>>>
>>> Attached is the new code, output, and logs. At the moment there are no
>>> entries in /home/export/ so I'm not sure why it is returning "f" and
>>> then another return with no name.
>>>
>>> I had an issue before with 3 entries in /home/export (test, test2,
>>> test3). It was returning 4 items from glusterfs_readdir() and they were
>>> all one letter names like "P", "[".
>>>
>>> The "count" parameter for glusterfs_readdir() doesn't appear to be used
>>> so I made it 0 for now. Changing it to other values has no effect.
>>>
>>>
>>> Thanks
>>> Rob
>>>
>>>
>>> Shehjar Tikoo wrote:
>>>> Hi
>>>>
>>>> Thanks for the report. The attached patch should fix this problem
>>>> for rc7. The test program, glfs.c, works fine for me with this
>>>> patch applied while using the volfiles supplied. Could you please
>>>> confirm if this works for your setup?
>>>>
>>>> Thanks
>>>> Shehjar
>>>>
>>>> Serial Thrilla wrote:
>>>>> Hey all, attached are the code and output of server and client.
>>>>>
>>>>> *Please be aware that the server and client run on the same machine*
>>>>>
>>>>> glusterfs_open() will return a file descriptor but glusterfs_fstat()
>>>>>  returns -1 for that descriptor.
>>>>>
>>>>> Is it normal for the file descriptor to change on each call to
>>>>> glusterfs_open() despite the same parameters?
>>>>>
>>>>> Also, I was having issues with glusterfs_readdir() but that wasn't
>>>>> working either so I suspect there's an issue with the descriptor.
>>>>>
>>>>> Please let me know if you need any more info.
>>>>>
>>>>> Attn core developers: Please let me know if you would like access to
>>>>> my dev box and I'll be happy to provide it.
>>>>>
>>>>> Thanks Rob
> 
> ------------------------------------------------------------------------
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.0.238 / Virus Database: 270.11.30/2026 - Release Date: 03/27/09 07:13:00
>