Am 18.07.2014 01:03, schrieb Karsten Blees:
Am 17.07.2014 19:05, schrieb René Scharfe:
Am 17.07.2014 14:45, schrieb Nguyễn Thái Ngọc Duy:
"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)?
That's a good question; thanks for stepping back and looking at the
bigger picture. If there is widespread OS support for a functionality
then we should use it and just provide a compatibility implementation
for those platforms lacking it. The downside is that compat code gets
Seeing that readlink() is left as a stub in compat/mingw.h that only
errors out, would the equivalent function on Windows be PathCanonicalize
For non-XSI-compliant platforms, we could keep the current implementation.
OK, so realpath() for Linux and the BSDs, mingw_realpath() wrapping
PathCanonicalize() for Windows and the current code for the rest?
Or re-implement a thread-safe version, e.g. applying resolve_symlink() from
lockfile.c to all path components.
Thread safety sounds good. We'd also need something like
normalize_path_copy() but without the conversion of backslashes to
slashes, in order to get rid of "." and ".." path components and
something like absolute_path() that doesn't die on error, no?
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.
On Windows, there *is* an absolute path length limit of 260 in the
normal case and a bit more than 32000 for some functions using the \\?\
namespace. So one could get away with using a constant-sized buffer for
a "remember the place and return later" function here.
Also, _getcwd can be asked to allocate an appropriately-sized buffer for
use, like GNU's get_current_dir_name, by specifying NULL as its first
Not having to move around at all as mentioned above is still better, of
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html