tahoe 26.4.1 chdir(2) problem

as of this posting, chdir(2) is now following symbolic links. As per the man page, this IS NOT what it is supposed to do. This is a recent change as of 5/13/26

Answered by DTS Engineer in 887828022
As per the man page, this IS NOT what it is supposed to do.

Please post the bit of the man page that makes you think that.

Because when I search the chdir man page the only mention I see of the text sym or link is this:

     [ELOOP]            Too many symbolic links were encountered in
                        translating the pathname.  This is taken to be
                        indicative of a looping symbolic link.

which suggests that it is intended to follow symlinks. And AFAIK this has been the case ever since symlinks were introduced.

Notably, the Posix spec has similar text and AFAIK this is standard across all Unices.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

As per the man page, this IS NOT what it is supposed to do.

Please post the bit of the man page that makes you think that.

Because when I search the chdir man page the only mention I see of the text sym or link is this:

     [ELOOP]            Too many symbolic links were encountered in
                        translating the pathname.  This is taken to be
                        indicative of a looping symbolic link.

which suggests that it is intended to follow symlinks. And AFAIK this has been the case ever since symlinks were introduced.

Notably, the Posix spec has similar text and AFAIK this is standard across all Unices.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

As of this posting, chdir(2) is now following symbolic links. As per the man page, this is NOT what it is supposed to do.

As a small expansion to what Quinn said, it's also not clear to me how the system could work if it DIDN'T follow symbolic links. Theoretically, you could expect everyone to call "realpath()" before calling "chdir", but the file system is an inherently unstable collection of race conditions[1]... so correctness would actually require looping between realpath & chdir until timing worked out such that you got a realpath[2] that happened to not include any symbolic links.

UNIX's broad semantic is to make symbolic links as "invisible" as possible, which allows apps that choose to ignore their existence without any additional effort. You can imagine a system that didn't work that way, but the APIs for that would look much more like how bookmarks are handled than the way symbolic links work.

[1] Many apps, particularly command line tools, are written in a way that ignores this reality, implicitly relying on the assumption that whatever they're manipulating won't change while they happen to be trying to manipulate it. To the extent that these tools work, this makes them "lucky", not correct.

[2] realpath said it would resolve all symbolic links and then return that path. It NEVER promised that something else would immediately come along and insert symbolic links back into the path it just returned. These issues are what lead to the creation of solutions like ".nofollow".

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

tahoe 26.4.1 chdir(2) problem
 
 
Q