Red Hat Bugzilla – Full Text Bug Listing
|Summary:||/bin/pwd couldn't find directory entry in `..' with matching i-node|
|Product:||[Fedora] Fedora||Reporter:||Zouhir Hafidi <zouhir.hafidi>|
|Component:||coreutils||Assignee:||Pete Graner <pgraner>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-08-21 15:18:33 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Zouhir Hafidi 2006-05-04 05:38:03 EDT
Description of problem: /bin/pwd says: couldn't find directory entry in `..' with matching i-node Version-Release number of selected component (if applicable): coreutils-5.93-7.2 How reproducible: always Steps to Reproduce: 1. cd to any subdir of / 2. /bin/pwd 3. Actual results: couldn't find directory entry in `..' with matching i-node Expected results: the name of the current dir Additional info: I'm using FC5 in a diskelss environment with unionfs and /bin/pwd doesn't work - cd / ; /bin/pwd ---> OK - cd /nfs_mounted_dir ; /bin/pwd ---> OK - cd /any_subdir ; /bin/pwd ---> NOT OK - cd /any_subdir ; pwd ---> OK with internal pwd command - if I get a copy of /bin/pwd from FC4 then cd /any_subdir ; /bin/pwd ---> OK
Comment 1 Jim Meyering 2006-05-04 05:49:32 EDT
I think this is due to dirent.d_ino not matching stat.st_ino numbers. IMHO, this is not a bug in coreutils, but there is a work-around in the upstream coreutils repository. Here's the ChangeLog comment: 2006-03-19 Jim Meyering <email@example.com> Work even in a chroot where d_ino values for entries in "/" don't match the stat.st_ino values for the same names. * getcwd.c (__getcwd): When no d_ino value matches the target inode number, iterate through all entries again, using lstat instead. Reported by Kenshi Muto in http://bugs.debian.org/355810. I'd like to confirm that its' the same problem. Can you build/test this, given a tarball? If so, reply to me privately and I'll send you one based on the latest upstream work.
Comment 2 Zouhir Hafidi 2006-05-04 06:14:51 EDT
Good news. I just built coreutils-6.0-cvs based on the latest upstream work and the new pwd command works as expected. Hope that an rpm with the fix will be available soon ;-) Thanks a lot
Comment 3 Jim Meyering 2006-05-04 06:23:15 EDT
Thanks for the quick feedback!
Comment 4 Jim Meyering 2006-05-04 07:38:47 EDT
For the record, here's the patch: http://cvs.savannah.gnu.org/viewcvs/coreutils/coreutils/lib/getcwd.c?r1=1.19&r2=1.20
Comment 5 Jim Meyering 2006-05-04 08:17:31 EDT
Created attachment 128603 [details] work around file system brokenness: d_ino/st_ino mismatch
Comment 6 Tim Waugh 2006-05-16 09:25:59 EDT
Please try this test update: https://www.redhat.com/archives/fedora-test-list/2006-May/msg00175.html Does that fix the problem for you?
Comment 7 Zouhir Hafidi 2006-05-16 10:43:02 EDT
yes, this rpm fixes the problem. Now /bin/pwd gives the right answer. Thanks
Comment 8 Guillaume Chazarain 2006-06-02 09:01:58 EDT
Why not use the getcwd syscall or /proc/self/exe ?
Comment 9 Guillaume Chazarain 2006-06-02 09:03:31 EDT
I meant /proc/self/cwd :-|
Comment 10 Guillaume Chazarain 2006-06-03 17:37:29 EDT
Created attachment 130453 [details] Use getcwd(3) if available regardless of AT_FDCWD The algorithm is slow without the ...at() syscalls, but even if we have them, I don't see why we should not use getcwd(3). Not for the speed but to have an algorithm less to look after.
Comment 11 Jim Meyering 2006-06-03 17:43:42 EDT
Because getcwd is buggy on some systems. On those systems, coreutils uses its replacement. See coreutils/m4/getcwd*.m4 for details.
Comment 12 Guillaume Chazarain 2006-06-06 05:31:14 EDT
Sorry, I don't get it. Currently in FC5 HAVE_PARTLY_WORKING_GETCWD and AT_FDCWD are defined, so we will never use the system getcwd(). This sounds wrong. Even if we have AT_FDCWD, we should try the system getcwd(), no ? And what about get_current_dir_name() ?