On Fri, Jan 24, 2014 at 10:05:14PM +0100, Torsten Bögershausen wrote:
> commit a1bbc6c0 "repack: rewrite the shell script in C" introduced
> a possible regression, when a Git repo is located on a Windows network share.
>
> When git gc is called on an already packed repository, it could fail like
> this:
> "fatal: renaming '.git/objects/pack/.tmp-xyz.pack' failed: Permission denied"
>
> Temporary *.pack and *.idx files remain in .git/objects/pack/
>
> In a1bbc6c0 the rename() function replaced the "mv -f" shell command.
>
> Obviously the -f option can also override a read-only file but
> rename() can not on a network share.
>
> Make the C-code to work similar to the shell script, by making the
> files writable before calling rename().
>
> Another solution could be to do the "chmod +x" in mingw_rename().
> This may be done in another commit, because
> a) It improves git gc only when Git for Windows is used
> on the client machine
> b) Windows refuses to delete a file when the file is read-only.
> So setting a file to read-only under Windows is a way for a user
> to protect it from being deleted.
> Changing the behaviour of rename() globally may not be what we want.
>
> Reported-by: Jochen Haag <zwanzi...@googlemail.com>
> Signed-off-by: Torsten Bögershausen <tbo...@web.de>
> ---
> builtin/repack.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/builtin/repack.c b/builtin/repack.c
> index ba66c6e..033b4c2 100644
> --- a/builtin/repack.c
> +++ b/builtin/repack.c
> @@ -324,6 +324,10 @@ int cmd_repack(int argc, const char **argv, const char
> *prefix)
> statbuffer.st_mode &= ~(S_IWUSR | S_IWGRP |
> S_IWOTH);
> chmod(fname_old, statbuffer.st_mode);
> }
> + if (!stat(fname, &statbuffer)) {
> + statbuffer.st_mode |= (S_IWUSR | S_IWGRP |
> S_IWOTH);
> + chmod(fname, statbuffer.st_mode);
> + }Are we sure that the file in question can never be a symlink? Because if it is, we'll end up changing the permissions on the wrong file. In general, I'm wary of changing permissions on a file to suit Windows's rename because of the symlink issue and the security issues that can result. Hard links probably have the same issue. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
