Re: [PATCH] abspath.c: use PATH_MAX in real_path_internal()

From: Karsten Blees <karsten.blees@gmail.com>
Date: Jul 17, 2014, 23:03 UTC
Message-ID: <53C8562C.4000304@gmail.com>
In-Reply-To: <53C80265.5030903@web.de>

Am 17.07.2014 19:05, schrieb René Scharfe:

> Am 17.07.2014 14:45, schrieb Nguyễn Thái Ngọc Duy:

[...]

Show 5 quoted lines

> "These routines have traditionally been used by programs to save the
> name of a working directory for the purpose of returning to it. A much
> faster and less error-prone method of accomplishing this is to open the
> current directory (.) and use the fchdir(2) function to return."
>

fchdir() is part of the POSIX-XSI extension, as is realpath(). So why not use realpath() directly (which would also be thread-safe)?

For non-XSI-compliant platforms, we could keep the current implementation. Or re-implement a thread-safe version, e.g. applying resolve_symlink() from lockfile.c to all path components.

If I may bother you with the Windows point of view:

There is no fchdir(), and I'm pretty sure open(".") won't work either.

fchdir() could be emulated using GetFileInformationByHandleEx(FileNameInfo). realpath() is pretty much what GetFinalPathNameByHandle() does. However, both of these APIs require Windows Vista.

Opening a handle to a directory can be done using FILE_FLAG_BACKUP_SEMANTICS, which AFAICT MSVCRT.dll's open() implementation does _not_ do (could be emulated in our mingw_open() wrapper, though).

...lots of work for little benefit, I would think.