/bin/pwd (getcwd) and symlinks

Chris Faylor cgf@cygnus.com
Wed Oct 18 12:42:00 GMT 2000


I've previously posted about this.  It probably shouldn't work this way but,
as Corinna pointed out, this change was made to fix a more serious problem
with find.

It's on my list of things to fix so it will be fixed eventually.

cgf

On Wed, Oct 18, 2000 at 06:09:25PM +0400, Andrej Borsenkow wrote:
>>
>> Ok.  HP-UX /bin/pwd prints the actual directory.  But, what does /bin/pwd on
>> Linux do?  Where is any documentation for what it should do for symlink?  I
>> haven't found anything useful that describes what happens for symlink.
>>
>
>It is not "what it should do" - it is how symlinks and getcwd are (typically)
>implemented.
>
>Symlinks are implemented by storing target name as symlink file content. When
>you open symlink, kernel implicitly opens target, giving you (dev,inode) - or
>vnode - of _target_. After this step, there is no way to recover the original
>name (or inode) of symlink.
>
>getcwd is implemented by fetching inode of current directory, scanning parent
>directory (..) and comparing inodes there with current inode. When it is
>found, directory entry gives you last part of absolute name. Than getcwd goes
>up (cd ..) and repeats it. It does it until it hits root (inode(.) ==
>inode(..)).
>
>If you combine both, you see, that there is no way getcwd can actually find
>_symlink_ name.
>
>As stated - this is typical implementation. YMMV :-) But I'm really curious to
>see any Unix-like system that does it differently.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com



More information about the Cygwin mailing list