Tue, 07 May 2013 05:04:11 +0900 largefiles: check existence of the file with case awareness of the filesystem stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 07 May 2013 05:04:11 +0900] rev 19160
largefiles: check existence of the file with case awareness of the filesystem Before this patch, largefiles extension always unlinks largefiles untracked on the target context in merging/updating after updating working directory. For example, it is assumed that the revision X consists of ".hglf/A" (and "A" implicitly) and revision Y consists of "a" (not ".hglf/A"). In the case of updating from X to Y, largefiles extension tries to unlink "A" after updating "a" in working directory. This causes unexpected unlinking "a" on the case insensitive filesystem. This patch checks existence of the file in the working context with case awareness of the filesystem to prevent from such unexpected unlinking. "lfcommands._updatelfile()" also unlinks target file in the case "largefile is tracked in the target context, but fails to be fetched". This patch doesn't apply "repo.dirstate.normalize()" in this case, because it should be already ensured in the manifest merging that there is no normal file colliding against any largefiles.
Tue, 07 May 2013 05:04:11 +0900 windows: check target type before actual unlinking to follow POSIX semantics stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 07 May 2013 05:04:11 +0900] rev 19159
windows: check target type before actual unlinking to follow POSIX semantics Creation and writing into target file via vfs (a.k.a opener) is done after "unlink()" target file, if it exists. For example, it is assumed that the revision X consists of file 'A', and the revision Y consists of file 'A/B'. Merging revision X into Y tries to "unlink()" on directory 'A' of 'A/B', before creation of file 'A'. On POSIX environment, directories should be removed by "rmdir(2)", and "unlink(2)" on directories fails. "unlink()" of Mercurial (and Python) uses "unlink(2)" directly, so unlinking in the merge case above would fail. In the other hand, on Windows environment, "unlink()" of Mercurial tries to rename before actual unlinking, to follow POSIX semantics: already opened file can be unlinked safely. This causes unexpected success in unlinking in the merge case above, even though directory 'A' is renamed to another. This confuses users. This patch checks whether target is directory or not before renaming, and raises IOError(errno.EPERM) if so, to follow POSIX semantics.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -2 +2 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip