Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionArmin W. Singer
2014-05-13 09:08:57 UTC
Created attachment 895059[details]
This is a very simple re-implementation of ls.
Description of problem:
Given a CIFS mounted filesystem, a (rather old) ELF 32-bit LSB executable
which tries to read the directory contents lists just nothing.
Strace reports that the getdents call fails due to ENOMEM.
The native /bin/ls, however, lists all files of the CIFS mounted directory.
A newly compiled executable can be used instead of the "rather old" one mentioned above. A rather old 32 bit system is needed to compile it, of course.
(Used Red Hat Linux release 7.2 (Enigma) as build system.)
Note: Not sure that the problem is located in glibc...
Version-Release number of selected component (if applicable):
glibc-2.12-1.132.el6_5.1.i686
kernel-2.6.32-431.5.1.el6.x86_64
How reproducible:
The 32 bit test "myls" executable is to be run with the CIFS mountpoint as an argument. It never lists any files.
Steps to Reproduce:
1. Compile the attached myls.c on a 32 bit platform.
2. Transfer the executable myls to the 64 bit platform. (32 bit support must be installed there.)
3. Establish a CIFS mount for test purposes.
4. Try /bin/ls to see that it lists files.
5. Try ./myls to see that is does not list files.
Actual results:
/bin/ls lists file names, ./myls does not.
Expected results:
Both /bin/ls and 32 bit ./myls should list all files of a CIFS mounted directory.
Additional info:
A precompiled 32 bit myls can be provided.
(In reply to Armin W. Singer from comment #0)
> Created attachment 895059[details]
> This is a very simple re-implementation of ls.
>
> Description of problem:
>
> Given a CIFS mounted filesystem, a (rather old) ELF 32-bit LSB executable
> which tries to read the directory contents lists just nothing.
> Strace reports that the getdents call fails due to ENOMEM.
Would you please provide the strace output? Can you reproduce this issue with a 32-bit kernel? Thanks.
Writing in English although I suppose you are German. I'm German too.
This is a rather old issue which has been worked around by using NFS instead of CIFS at customer site.
They had a (very) old executable (no sources of course), put it onto a new Linux and tried to list files on a CIFS mounted filesystem. This did not work.
So I did some investigations in the past with own test code. I also used strace but I cannot provide the full trace now. The 32-bit executable on a native 32-bit system worked well.
Florian, you may set this bug to WONTFIX, if you ask me. I think nobody else will run into the same problem in the future. These old executables should
simply die.
However, could you reproduce it?
Created attachment 895059 [details] This is a very simple re-implementation of ls. Description of problem: Given a CIFS mounted filesystem, a (rather old) ELF 32-bit LSB executable which tries to read the directory contents lists just nothing. Strace reports that the getdents call fails due to ENOMEM. The native /bin/ls, however, lists all files of the CIFS mounted directory. A newly compiled executable can be used instead of the "rather old" one mentioned above. A rather old 32 bit system is needed to compile it, of course. (Used Red Hat Linux release 7.2 (Enigma) as build system.) Note: Not sure that the problem is located in glibc... Version-Release number of selected component (if applicable): glibc-2.12-1.132.el6_5.1.i686 kernel-2.6.32-431.5.1.el6.x86_64 How reproducible: The 32 bit test "myls" executable is to be run with the CIFS mountpoint as an argument. It never lists any files. Steps to Reproduce: 1. Compile the attached myls.c on a 32 bit platform. 2. Transfer the executable myls to the 64 bit platform. (32 bit support must be installed there.) 3. Establish a CIFS mount for test purposes. 4. Try /bin/ls to see that it lists files. 5. Try ./myls to see that is does not list files. Actual results: /bin/ls lists file names, ./myls does not. Expected results: Both /bin/ls and 32 bit ./myls should list all files of a CIFS mounted directory. Additional info: A precompiled 32 bit myls can be provided.