Document behavior when updating a tracee's cwd #31
Description
It's worth mentioning that, in the process of translating rename(), I found that the original proot also changed tracee's cwd.
https://github.com/proot-me/proot/blob/7ac33878f95237401b9759db853a6b8c37899675/src/syscall/exit.c#L296
Specifically, if the path being rename() is the same as current tracee's cwd, then it will update the current tracee's cwd filed to the new path.
I think this is something similar to "what happens when you move an open file". The handling in orignal proot is a very hack method (that is, updating the cwd after rename() syscall ), so I'm not implementing it in proot-rs at the moment, just leaving a TODO marker here.
It tries to emulate a phenomenon in the Linux filesystem. But I think it's hacky for several reasons.
- it may conflict with the --bind function of proot-rs in some cases. For example, if /foo is bound to /bar and tracee's cwd is "/bar", it won't sense rename("/foo", "/foo2") because "/foo" is not a cwd prefix. So this hack will be bypassed.
- In addition, in the original proot only the cwd of the tracee calling rename() is checked. However, it is possible that one tracee's rename() modifies the prefix of another tracee's cwd, but is not sensed by proot.
Yes, but I haven't actually found a document that defines this behavior so far, not in lwn, and seemingly not in POSIX. So I think we can let it go for now.