Junio C Hamano <gitster@xxxxxxxxx> writes:
>> So I dunno. I'd be OK to just rip the feature out in favor of doing
>> those chdir()s. But that seems like a non-zero amount of work versus
>> leaving, and the existing code has the benefit that if another caller
>> shows up, it could benefit from the feature.
>
> I am OK to keep the series as-is, and leave it to a possible future
> work to remove the need for chdir even for long paths and not having
> to return an error with ENAMETOOLONG; when such an update happens,
> the "fail if need to chdir" feature this patch is adding will become
> a no-op.
For example, as this is UNIX-only codepath, I wonder if something
like this would be a good way to avoid chdir() that would cause
trouble.
- obtain a fd from socket(2)
- check if path is too long to fit in sa->sun_path
- if it does, bind(2) the fd to the address
- if it does not, fork(2) a child and
- in the child, chdir(2) there and use the shortened path
to bind(2), and exit(3)
- the parents just wait(2)s for the child to return. By the
time it dies, the fd would be successfully bound to the
path.
- now we have a file descriptor that is bound at that path.
