Mail Archives: cygwin/2000/10/18/15:43:34
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 AT sourceware DOT cygnus DOT com
- Raw text -