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 <[email protected]> 写道： > 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 <[email protected]> > Date: 2011/5/5 > Subject: Re: bug#8620: Strange problem for ls > To: errik <[email protected]> > 抄送： [email protected] > > > 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 [email protected] > instead of [email protected], 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 [email protected] +1-801-349-2682 > Libvirt virtualization library http://libvirt.org >
