Bug 190656 - /bin/pwd couldn't find directory entry in `..' with matching i-node
/bin/pwd couldn't find directory entry in `..' with matching i-node
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Graner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-04 05:38 EDT by Zouhir Hafidi
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
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:


Attachments (Terms of Use)
work around file system brokenness: d_ino/st_ino mismatch (5.16 KB, patch)
2006-05-04 08:17 EDT, Jim Meyering
no flags Details | Diff
Use getcwd(3) if available regardless of AT_FDCWD (641 bytes, patch)
2006-06-03 17:37 EDT, Guillaume Chazarain
no flags Details | Diff

  None (edit)
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  <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:

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

Note You need to log in before you can comment on or make changes to this bug.