git/server-info.c, branch v2.6.2

add_info_ref(): rewrite to take an object_id argument

2015-05-25T19:19:35Z

Signed-off-by: Michael Haggerty Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

each_ref_fn: change to take an object_id parameter

2015-05-25T19:19:27Z

Change typedef each_ref_fn to take a "const struct object_id *oid" parameter instead of "const unsigned char *sha1". To aid this transition, implement an adapter that can be used to wrap old-style functions matching the old typedef, which is now called "each_ref_sha1_fn"), and make such functions callable via the new interface. This requires the old function and its cb_data to be wrapped in a "struct each_ref_fn_sha1_adapter", and that object to be used as the cb_data for an adapter function, each_ref_fn_adapter(). This is an enormous diff, but most of it consists of simple, mechanical changes to the sites that call any of the "for_each_ref" family of functions. Subsequent to this change, the call sites can be rewritten one by one to use the new interface. Signed-off-by: Michael Haggerty Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

update-server-info: create info/* with mode 0666

2015-01-06T21:46:52Z

Prior to d38379e (make update-server-info more robust, 2014-09-13), we used a straight "fopen" to create the info/refs and objects/info/packs files, which creates the file using mode 0666 (less the default umask). In d38379e, we switched to creating the file with mkstemp to get a unique filename. But mkstemp also uses the more restrictive 0600 mode to create the file. This was an unintended side effect that we did not want, and causes problems when the repository is served by a different user than the one running update-server-info (it is not readable by a dumb http server running as `www`, for example). We can fix this by using git_mkstemp_mode and specifying 0666 to make sure that the umask is honored. Note that we could also say "just use core.sharedrepository", as we do call adjust_shared_perm on the result before renaming it into place. But that should not be necessary as long as everybody involved is using permissive umask to allow HTTP server to read necessary files. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

server-info: clean up after writing info/packs

2014-09-15T18:39:54Z

We allocate pack information in a static global list but never clean it up. This leaks memory, and means that calling update_server_info twice will generate a buggy file (it will have duplicate entries). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

make update-server-info more robust

2014-09-15T18:38:13Z

Since "git update-server-info" may be called automatically as part of a push or a "gc --auto", we should be robust against two processes trying to update it simultaneously. However, we currently use a fixed tempfile, which means that two simultaneous writers may step on each other's toes and end up renaming junk into place. Let's instead switch to using a unique tempfile via mkstemp. We do not want to use a lockfile here, because it's OK for two writers to simultaneously update (one will "win" the rename race, but that's OK; they should be writing the same information). While we're there, let's clean up a few other things: 1. Detect write errors. Report them and abort the update if any are found. 2. Free path memory rather than leaking it (and clean up the tempfile when necessary). 3. Use the pathdup functions consistently rather than static buffers or manually calculated lengths. This last one fixes a potential overflow of "infofile" in update_info_packs (e.g., by putting large junk into $GIT_OBJECT_DIRECTORY). However, this overflow was probably not an interesting attack vector for two reasons: a. The attacker would need to control the environment to do this, in which case it was already game-over. b. During its setup phase, git checks that the directory actually exists, which means it is probably shorter than PATH_MAX anyway. Because both update_info_refs and update_info_packs share these same failings (and largely duplicate each other), this patch factors out the improved error-checking version into a helper function. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

update-server-info: Shorten read_pack_info_file()

2010-07-19T18:13:52Z

The correct responses to a D and a T line in .git/objects/info/packs are the same, so combine their case arms. In both cases we already ‘goto’ out of the switch so while at it, remove a redundant ‘break’ to avoid yet another line of code. Signed-off-by: Ralf Thielow Reviewed-by: Jonathan Nieder gmail.com> Signed-off-by: Junio C Hamano

Merge branch 'ar/unlink-err'

2009-05-18T16:01:06Z

* ar/unlink-err: print unlink(2) errno in copy_or_link_directory replace direct calls to unlink(2) with unlink_or_warn Introduce an unlink(2) wrapper which gives warning if unlink failed

Fix a bunch of pointer declarations (codestyle)

2009-05-01T22:17:31Z

Essentially; s/type* /type */ as per the coding guidelines. Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano

replace direct calls to unlink(2) with unlink_or_warn

2009-04-30T01:37:41Z

This helps to notice when something's going wrong, especially on systems which lock open files. I used the following criteria when selecting the code for replacement: - it was already printing a warning for the unlink failures - it is in a function which already printing something or is called from such a function - it is in a static function, returning void and the function is only called from a builtin main function (cmd_) - it is in a function which handles emergency exit (signal handlers) - it is in a function which is obvously cleaning up the lockfiles Signed-off-by: Alex Riesen Signed-off-by: Junio C Hamano

Use git_pathdup instead of xstrdup(git_path(...))

2008-10-31T00:52:24Z

Signed-off-by: Junio C Hamano