Bug 190656 - /bin/pwd couldn't find directory entry in `..' with matching i-node
Summary: /bin/pwd couldn't find directory entry in `..' with matching i-node
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
(Show other bugs)
Version: 5
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Pete Graner
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-05-04 09:38 UTC by Zouhir Hafidi
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-21 19:18:33 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

Description Zouhir Hafidi 2006-05-04 09:38:03 UTC
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 09:49:32 UTC
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 10:14:51 UTC
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 10:23:15 UTC
Thanks for the quick feedback!

Comment 4 Jim Meyering 2006-05-04 11:38:47 UTC
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 12:17:31 UTC
Created attachment 128603 [details]
work around file system brokenness: d_ino/st_ino mismatch

Comment 6 Tim Waugh 2006-05-16 13:25:59 UTC
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 14:43:02 UTC
yes, this rpm fixes the problem. Now /bin/pwd gives the right answer.

Thanks

Comment 8 Guillaume Chazarain 2006-06-02 13:01:58 UTC
Why not use the getcwd syscall or /proc/self/exe ?

Comment 9 Guillaume Chazarain 2006-06-02 13:03:31 UTC
I meant /proc/self/cwd :-|

Comment 10 Guillaume Chazarain 2006-06-03 21:37:29 UTC
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 21:43:42 UTC
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 09:31:14 UTC
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.