Bug 190656

Summary: /bin/pwd couldn't find directory entry in `..' with matching i-node
Product: [Fedora] Fedora Reporter: Zouhir Hafidi <zouhir.hafidi>
Component: coreutilsAssignee: Pete Graner <pgraner>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: guichaz, meyering
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-21 15:18:33 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
work around file system brokenness: d_ino/st_ino mismatch
Use getcwd(3) if available regardless of AT_FDCWD none

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):

How reproducible:

Steps to Reproduce:
1. cd to any subdir of /
2. /bin/pwd
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  <jim@meyering.net>

        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:

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:


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.

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() ?