getcwd: work with symbolic links - unix

Question

int
main(void)
{
char *ptr;
size_t size;
if (chdir("/usr/spool/uucppublic") < 0)
err_sys("chdir failed");
ptr = path_alloc(&size);
/* our own function */
if (getcwd(ptr, size) == NULL)
err_sys("getcwd failed");
printf("cwd = %s\n", ptr);
exit(0);
}
$ ./a.out
cwd = /var/spool/uucppublic
$ ls -l /usr/spool
lrwxrwxrwx 1 root 12 Jan 31 07:57 /usr/spool -> ../var/spool
Note that chdir follows the symbolic link—as we expect it to, from
Figure 4.17 — but when it goes up the directory tree, getcwd has no
idea when it hits the /var/spool directory that it is pointed to by
the symbolic link /usr/spool. This is a characteristic of symbolic
links.
This all above is from book Advanced Unix Programming by Rago and Stevens.
First, chdir follows symblic links, but what does kernel store under current working directory of the process? Just uucppublic?
Second, what did the author want to state by saying
getcwd has no idea when hits /var/spool
As I understand, getcwd should start reading inode of .. in folder uucppublic to jump to directory spool with parent var, not usr. That is why getcwd should not care whether there was a symbolic or not. Because chdir follows symbolic links.

Answer 1

It looks like you got the idea, but you're parsing the English wrong.
getcwd has no idea when it hits the /var/spool directory that it is pointed to by the symbolic link /usr/spool
"when it hits the /var/spool directory" is a modifier on the whole clause:
getcwd has no idea that it is pointed to by the symbolic link /usr/spool
and in that sentence, the "it" is "the /var/spool directory". So read it like this:
getcwd has no idea that the /var/spool directory is pointed to by the symbolic link /usr/spool
The snippet you pulled out:
getcwd has no idea when hits /var/spool
is not a meaningful fragment because it keeps the modifying "when" clause but drops the more important "that" clause which is the object of "has no idea..."
As a side note, you are working from an old book, so you should be aware that things have changed a little. getcwd is a syscall now (in Linux at least) so the old algorithm (traverse .. and search for matching inode numbers) is no longer used. The dedicated syscall gives the same result faster.