coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#8620: Strange problem for ls


From: errik
Subject: Re: bug#8620: Strange problem for ls
Date: Fri, 6 May 2011 14:50:02 +0800

Hi All,

   It seems I can solve the issue by add compile option:

-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64

Thanks,
Erik
在 2011年5月6日 上午10:00,errik <address@hidden> 写道:
> Dears,
>       As Eric Blake mentioned, ls takes measures to guarantee that
> off_t is 64-bits. There are two problems need your help
> 1) How ls do this?  I din't notice any clues from the source code of
> ls. Sorry for my poor linux coding experience.
> 2) As in the previous thread, the code ("readdir") has problem on cifs
> client directory, is 1) the solutiuon to solve the issue?
>
>
> Looking forward to your response.
>
> Thanks a lot,
> Eric
>
>
> ---------- Forwarded message ----------
> From: Eric Blake <address@hidden>
> Date: 2011/5/5
> Subject: Re: bug#8620: Strange problem for ls
> To: errik <address@hidden>
> 抄送: address@hidden
>
>
> On 05/04/2011 11:45 PM, errik wrote:
>> Dears,
>>       Actually this is not a bug report, so sorry to do this because I
>> don't know the mail address of  Richard M. Stallman, and David
>> MacKenzie.
>
> This is the correct address.  'ls --help' shows you the names of the
> original authors, not the current maintainers, but the original authors
> would have just pointed you to the current maintainers (at this address)
> in the first place.  (Well, you could have used address@hidden
> instead of address@hidden, in order to avoid raising it as a bug).
>
>> These days, there is a problem that trouble me so much. I write a
>> simple code to get all the files under  a directory and compile the
>> code on RedHat 6 i686 machine. The code is as below:
>>
>> #include <sys/types.h>
>> #include <errno.h>
>> #include <dirent.h>
>> #include <stdio.h>
>> #include <unistd.h>
>> int main(int argc, char **argv)
>> {
>>       printf("Try to list the directory: %s\n", argv[1]);
>>       DIR * dir = NULL;
>>     char * path = argv[1];
>>     dir = opendir(path);
>>     errno = 0;
>>       if(NULL == dir)
>>       {
>>               printf("Failed to open the dir with errno: %d\n", errno);
>>                 return -1;
>>       }
>>     struct dirent * dir_entry = NULL;
>>     while(dir_entry = readdir(dir))
>>       {
>>               printf("file: %s\n", dir_entry->d_name);
>
> You have to reset 'errno = 0;' here, before the next readdir() call...
>
>>       }
>>     printf("error :%d\n", errno);
>
> ...if you want errno to be valid here (since readdir is required to
> leave errno unchanged when successfully returning NULL, but printf is
> allowed to populate errno with junk on success).  In other words, your
> code may be printing a spurious errno value that was left over from some
> other call, rather than an actual readdir failure.
>
>>     return 0;
>> }
>>
>> After compiled the code on RedHat 6 32 bits machine and then copy the
>> binary to RedHat 6 64 bits machine, it can work correctly when the
>> parameter for the program is a local directory.
>> But "readdir" always failed if the parameter is a cifs client
>> directory, the errno is 12.
>
> aka ENOMEM. Which is an odd value, but might be plausibly explained if
> you aren't compiling for LARGE_FILES.
>
>>
>>
>> Then I downloaded the souce code of "ls" from  GNU site and compiled
>> it on RedHat 6 32 bits, the binary can also works with cifs client
>> directory.
>>
>>>From the code of ls, it also use opendir and readdir to list the directory.
>>
>>
>> It's strange ls can work but my simple code can't work.
>
> ls takes measures to guarantee that off_t is 64-bits, even on 32-bit
> Linux; I don't see that you have taken those same measures.  Plus, until
> you fix your programming bug of errno handling, all bets are off.
>
> --
> Eric Blake   address@hidden    +1-801-349-2682
> Libvirt virtualization library http://libvirt.org
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]