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).
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
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> _______________________________________________ Gluster-devel mailing
>>> list Gluster-devel@xxxxxxxxxx
>>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database:
>> 270.11.29/2024 - Release Date: 03/26/09 07:12:00
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel@xxxxxxxxxx
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.557 / Virus Database: 270.11.28 - Release Date: 3/25/2009 12:00 AM
struct dirent
{
#ifndef __USE_FILE_OFFSET64
__ino_t d_ino;
__off_t d_off;
#else
__ino64_t d_ino;
__off64_t d_off;
#endif
unsigned short int d_reclen;
unsigned char d_type;
char d_name[256]; /* We must not include limits.h! */
};
