On Thursday 18 February 2010 02:16:23 Junio C Hamano wrote:
> When creating a loose object, we normally mmap(2) the entire file, and
> hash and then compress to write it out in two separate steps for
> efficiency.
>
> This is perfectly good for the intended use of git---nobody is supposed to
> be insane enough to expect that it won't break anything to muck with the
> contents of a file after telling git to index it and before getting the
> control back from git.
This makes it sound as if the user is to blame, but IMHO we're just
not checking the input well enough. The user should never be able to
corrupt the repository (without git noticing!) just by running a git
command and manipulating the worktree in parallel. The file data at
any given time is just user input, and you also cannot (I hope;
otherwise let's fix it!) corrupt the repository merely by typoing some
command arguments.
(Mucking around in .git is an entirely different matter, but that is
off limits.)
> This teaches the index_mem() codepath to be paranoid and hash and compress
> the data after reading it in core. The contents hashed may not match the
> contents of the file in an insane use case, but at least this way the
> result will be internally consistent.
Doesn't that trigger on windows, where xmmap() already makes a copy?
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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