coreutils
[Top][All Lists]
Advanced

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

Fwd: bug#8620: Strange problem for ls


From: errik
Subject: Fwd: bug#8620: Strange problem for ls
Date: Fri, 6 May 2011 10:00:46 +0800

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]