Description of problem: I can't enter/list some directorys on a cifs-share after updating to rawhide some days ago. I retrieve following error message: $ LC_ALL=C ls ls: reading directory .: Invalid argument Disabling selinux did not help. Happens with two different CIFS-Servers (all samba, one on debian, one on FC4) I looked closer and found out that the total lenght of the path or the filesnames seem to be related. E.g. only those dirs with a one or more files with really long filesnames don't get displayed. I was not able to hunt it down to a specific lenght :-/ I tried booting 2.6.17-1.2174_FC5 again (I had it still installed after updating to rawhide) and accessing those dirs works fine there. Version-Release number of selected component (if applicable): 2.6.17-1.2630.fc6 How reproducible: Always, only tested on x86_64, don't have a i386 rawhide machine around to test.
I am also experiencing the same issue. When i am trying to access the windows share C$ it will not list and give error message ls: reading directory .: Invalid argument. However it displays some subdirectories correctly. However it also fails to list other sub directories. So it may be related to long names. I do have files with really long names. Is this a problem with cifs/samba or with ls program which can not handle the filenames correctly. However if i mount the same windows share in nautilus, it displays the directory correctly. So i am assuming that problem is with how ls handles the long file name.
I am also experiencing the same issue. When i am trying to access the windows share C$ it will not list and give error message ls: reading directory .: Invalid argument. However it displays some subdirectories correctly. However it also fails to list other sub directories. So it may be related to long names. I do have files with really long names. Is this a problem with cifs/samba or with ls program which can not handle the filenames correctly. However if i mount the same windows share in nautilus, it displays the directory correctly. So i am assuming that problem is with how ls handles the long file name. Version Fedora Core 6 Test 3, fully patched. i386 rawhide
Crap, hit the same problem on another machine in another network after updateing that i386-system to rawhide; the server is running FC5
Any updates on this issue. I know Fedora Core 6 is in freeze. However i thought that bugs will be fixed.
Problem still present; now also seen on a third machine with FC5 after the recent kernel-update to 2.6.18 was installed on it
*** This bug has been marked as a duplicate of 211070 ***