Am 18.07.2014 13:32, schrieb René Scharfe: > 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 less testing. >
I just noticed that in contrast to the POSIX realpath(), our real_path() doesn't require the last path component to exist. I don't know if this property is required by the calling code, though. > Seeing that readlink() You mean realpath()? We don't have a stub for that yet. > is left as a stub in compat/mingw.h that only errors out, would the > equivalent function on Windows be PathCanonicalize > (http://msdn.microsoft.com/en-us/library/windows/desktop/bb773569%28v=vs.85%29.aspx)? > PathCanonicalize() doesn't return an absolute path, the realpath() equivalent would be GetFullPathName() (doesn't resolve symlinks) or GetFinalPathNameByHandle() (requires Vista, resolves symlinks, requires the path to exist). >> 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? > Windows can handle forward slashes, so normalize_path_copy works just fine. >> 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. > The current directory is pretty much the only exception to the \\?\ trick [1]. So a fixed buffer for getcwd() would actually be fine on Windows (although it would have to be 3 * PATH_MAX, as PATH_MAX wide chars will convert to at most 3 * PATH_MAX UTF-8 chars). However, a POSIX conformant getcwd must fail with ERANGE if the buffer is too small. So a better alternative would be to add a strbuf_getcwd() that works similar to strbuf_readlink() (i.e. resize the buffer until its large enough). Side note: the 'hard' 260 limit for the current directory also means that as long as we *simulate* realpath() via chdir()/getcwd(), long paths [1] don't work 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 parameter > (http://msdn.microsoft.com/en-us/library/sf98bd4y.aspx). > We use nedmalloc in the Windows builds, so unfortuately we cannot free memory allocated by MSVCRT.dll. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa365530%28v=vs.85%29.aspx [2] https://github.com/msysgit/git/commit/84393750 -- 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
