From: Junio C Hamano <hidden> Date: 2016-12-19 18:15:54
Nguyễn Thái Ngọc Duy [off-list ref] writes:
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
Will this fix the problem I'm replying to? I don't know. I found this
while checking the code and it should be fixed regardless.
Yeah, from a cursory read, it is a step in the right direction to
check the return value of fstat().
Shouldn't the error-return path in the second hunk rollback the
lockfile to clean after itself? The existing "Oh, we cannot chmod
to match the original" check that comes immediately after shares the
same issue, so this is not a new problem, but making an existing one
worse.
@@ -2194,7 +2194,12 @@ int git_config_set_multivar_in_file_gently(const char *config_filename,gotoout_free;}-fstat(in_fd,&st);+if(fstat(in_fd,&st)==-1){+error_errno(_("fstat on %s failed"),config_filename);+ret=CONFIG_INVALID_FILE;+gotoout_free;+}+contents_sz=xsize_t(st.st_size);contents=xmmap_gently(NULL,contents_sz,PROT_READ,MAP_PRIVATE,in_fd,0);
@@ -2414,7 +2419,10 @@ int git_config_rename_section_in_file(const char *config_filename,gotounlock_and_out;}-fstat(fileno(config_file),&st);+if(fstat(fileno(config_file),&st)==-1){+ret=error_errno(_("fstat on %s failed"),config_filename);+gotoout;+}if(chmod(get_lock_file_path(lock),st.st_mode&07777)<0){ret=error_errno("chmod on %s failed",
On Mon, Dec 19, 2016 at 10:14:27AM -0800, Junio C Hamano wrote:
Shouldn't the error-return path in the second hunk rollback the
lockfile to clean after itself? The existing "Oh, we cannot chmod
to match the original" check that comes immediately after shares the
same issue, so this is not a new problem, but making an existing one
worse.
OK. How about two more patches on top (or bottom, does not matter)?
The second one should fix this. The first is sort of "good to do".
[PATCH 1/2] config.c: rename label unlock_and_out
[PATCH 2/2] config.c: handle lock file in error case in git_config_rename_...
--
Duy
There are two ways to unlock a file: commit, or revert. Rename it to
commit_and_out to avoid confusion.
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -2416,7 +2416,7 @@ int git_config_rename_section_in_file(const char *config_filename,if(!(config_file=fopen(config_filename,"rb"))){/* no config file means nothing to rename, no error */-gotounlock_and_out;+gotocommit_and_out;}if(fstat(fileno(config_file),&st)==-1){
@@ -2478,7 +2478,7 @@ int git_config_rename_section_in_file(const char *config_filename,}}fclose(config_file);-unlock_and_out:+commit_and_out:if(commit_lock_file(lock)<0)ret=error_errno("could not write config file %s",config_filename);
We could rely on atexit() to clean up everything, but let's be
explicit when we can. And it's good anyway because the function is
called the second time in the same process, we're in trouble.
This function should not affect the successful case because after
commit_lock_file() is called, rollback_lock_file() becomes no-op.
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
config.c | 1 +
1 file changed, 1 insertion(+)