Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > Hi, > > On Mon, 15 Oct 2007, Eli Zaretskii wrote: > >> > Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST) >> > From: Johannes Schindelin <Johannes.Schindelin@xxxxxx> >> > cc: Alex Riesen <raa.lkml@xxxxxxxxx>, ae@xxxxxx, tsuna@xxxxxxxxxxxxx, >> > git@xxxxxxxxxxxxxxx, make-w32@xxxxxxx >> > >> > The problem is not so much opening, but determining if an existing file >> > and a file in the index have the same name. >> > >> > For example, "README" in the index, but "readme" in the working directory, >> > will be handled as "deleted/untracked" by the current machinery. IOW git >> > will not know that what it gets from readdir() as "readme" really is the >> > same file as "README" in the index. >> >> That's because you think file names are simple strings and can be >> compared by simple string comparison. > > Almost... > >> This na?ve view is not true even on POSIX systems: "foo/bar" and >> "/a/b/foo/bar" can be the same file, as well as "/a/b/c/d" and "/x/y/z", >> given the right symlinks. > > ... not quite, ah ... > >> But for some reason that eludes me, people who are accustomed to POSIX >> stop right there and in effect say "file names are strings, if we only >> make them absolute and resolve links". > > ... yes! There you have it. Absolute filenames, resolved by > readlink() are assumed to be the unique (!) identifiers for the > contents. They aren't. One can mount the same file system several times in different places. In Linux, one can even mount directories and files to several places at once. Most Unices also support some case-insensitive file systems, and readlink does not canonicalize the casing. > _Note:_ absolute paths _without_ readlink() resolving are _still_ > unique identifiers; this time for files/symlinks. Not even that. A unique identifier for files would imply that touching the file does not affect, say, the access times of files with other unique identifiers. -- David Kastrup - 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
