LinuxQuestions.org - Problem with stat on cifs.

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - Problem with stat on cifs. (https://www.linuxquestions.org/questions/programming-9/problem-with-stat-on-cifs-852983/)

Problem with stat on cifs.

Hi,

i have Ubuntu10.10 (kernel-2.6.35-22-generic) installed.

struct stat StatBuff;

Example1:
iRet = stat("/mnt/win/data", &Statuff);
if (-1 == iRet)
{
perror("statfail");
}

Example2:
pDir = opendir("/mnt/win/data");
if (NULL != pDir)
{
if ((dp = readdir(pDir)) != NULL)
{
iRet = stat(dp->d_name, &StatBuff);
if (-1 == iRet)
{
perror("statfail");
}
}
}

I have mounted a windows share folder on /mnt. When i gave any directory within /mnt/ to stat function it fails with errorno 75. perror shows "Value too large for defined data type".

Example 1 is fail but Example 2 works fine.
Can any one tell me meanning of error or why Example 1 gets fail here?

Please help me. Its urgent.

Hi,

Maybe the following would be of use:

https://bugs.launchpad.net/ubuntu/+s...ts/+bug/455122

Especially if your dev environment is i386

Andy T

Update: I found that by googling:

CIFS "Value too large for defined data type

As a quick fix apparently you can add:

noserverino, nounix

To the CIFS mount options - only a short term fix tho'

Alternatively you could post the code and some context in a bit more detail (I noticed a typo in your listing which would never have compiled...)

If you do, don't forget to wrap it in [code] tags.

Regards,

Andy T

Quote:

Originally Posted by redhatstand (Post 4206817)

Hi,

Thanks for reply...with "noserverino, nounix" solved the problem.

Following is the detail code if require:

Code:

Example1:

int main()

{

        int iRet;

        struct stat StatBuff;



        iRet = stat("/mnt/win/data", &StatBuff);

        if (-1 == iRet)

        {

                perror("statfail");

        }



        if ((StatBuff.st_mode & S_IFLNK) == S_IFLNK)

        {

                printf("\nS_IFLNK");

                return 0;

        }



        if ((StatBuff.st_mode & S_IFDIR) == S_IFDIR)

        {

                printf("\nS_IFDIR");

                return 0;

        }



        return 0;

}





Example2:

int main()

{

        int iRet;

        DIR *pDir;

        struct stat StatBuff;

        struct dirent *dp;

        pDir = opendir("/mnt/win/data");

        if (NULL != pDir)

        {

                if ((dp = readdir(pDir)) != NULL)

                {

                        iRet = stat(dp->d_name, &StatBuff);

                        if (-1 == iRet)

                        {

                                perror("statfail");

                        }

                        else

                        {

                                if ((StatBuff.st_mode & S_IFLNK) == S_IFLNK)

                                {

                                        printf("\nS_IFLNK");

                                        return 0;

                                }



                                if ((StatBuff.st_mode & S_IFDIR) == S_IFDIR)

                                {

                                        printf("\nS_IFDIR");

                                        return 0;

                                }

                        }

                }

        }



        return 0;

}

Excellent, glad I could help.

Since that did appear to fix the problem, that thread goes on to say something about a change in the defaults for gcc and large file support:

You may want to follow the thread as I have no idea what those options do! Hmm, maybe I should have mentioned that more clearly :-)

Regards,

Andy T

Quote:

Originally Posted by redhatstand (Post 4207650)

Sir, i gone through the thread but i can't understand it properly. If you explain it in more details that will be helpful for all of us.

Hi,

As it happens I am in the midst of a samba / cifs related project:

Mounting with noserverino forces the samba client to generate inode numbers, where without the option the inode numbers would be created by the server.

Looks like the server is generating huge (64 bit) inode numbers, but one or more apps on your system have been compiled without support for that by the distro maintainers.

I have not tried any of the below options as I work exclusively with 64 bit machines and I suspect your client is 32 bit, but:

It may be that you simply need to add -D_FILE_OFFSET_BITS=64 when compiling _your_ app, OR

If the compile problem is with your samba client software, you could try compiling samba-client from source with -D_FILE_OFFSET_BITS=64 as a configure option, OR

Alternatively it looks like this could be fixed by the distro maintainers, so you could just wait.

Looks like the nolinux mentioned was a blind alley, so I would remove that.

Andy T

Quote:

Originally Posted by redhatstand (Post 4208525)

Thank you sir