GNU bug report logs - #8620
Strange problem for ls

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8620 in the body.
You can then email your comments to 8620 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: errik <waitingfor2009marry <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Strange problem for ls
Date: Thu, 5 May 2011 13:45:39 +0800

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.


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);
	}
    printf("error :%d\n", errno);
    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.


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.

Is there anyone can tell me the difference or forward the mail to
Richard M. Stallman, and David MacKenzie?

Thanks,
Erik

Message #8 received at 8620 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: errik <waitingfor2009marry <at> gmail.com>
Cc: 8620 <at> debbugs.gnu.org
Subject: Re: bug#8620: Strange problem for ls
Date: Thu, 05 May 2011 09:03:59 -0600

[Message part 1 (text/plain, inline)]

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 coreutils <at> gnu.org
instead of bug-coreutils <at> gnu.org, 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   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at 8620 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
Cc: 8620 <at> debbugs.gnu.org
Subject: Re: bug#8620: Strange problem for ls
Date: Fri, 06 May 2011 09:40:43 +0100

tags 8620 notabug
close 8620

On 06/05/11 07:50, errik wrote:
> Hi All,
> 
>    It seems I can solve the issue by add compile option:
> 
> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64

Just the latter.
http://www.pixelbeat.org/programming/gcc/c_c++_notes.html#LFS

I'm closing this...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.