Re: Bug in get_pwd_cwd() in Windows?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 21.07.2014 16:13, schrieb Duy Nguyen:
This function tests if $PWD is the same as getcwd() using st_dev and
st_ino. But on Windows these fields are always zero
(mingw.c:do_lstat). If cwd is moved away, I think falling back to $PWD
is wrong. I don't understand the use of $PWD in the first place.
1b9a946 (Use nonrelative paths instead of absolute paths for cloned
repositories - 2008-06-05) does not explain much.

The commit message reads:

  Particularly for the "alternates" file, if one will be created, we
  want a path that doesn't depend on the current directory, but we want
  to retain any symlinks in the path as given and any in the user's view
  of the current directory when the path was given.

The intent of the patch seems to be to prefer $PWD if it points to the same directory as the one returned by getcwd() in order to preserve "the user's view". That's why it introduces make_nonrelative_path() (now called absolute_path()), in contrast to make_absolute_path() (now called real_path()).

I imagine it's useful e.g. if your home is accessed through a symlink:

	/home/foo -> /some/boring/mountpoint

Then real_path("bar") would give you "/some/boring/mountpoint/bar", while absolute_path("bar") returned "/home/foo/bar". Not resolving symlinks keeps the path friendly in this case. And it keeps working even after the user's home is migrated to /a/bigger/partition and /home/foo is updated accordingly.

René

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]