Re: Git changes permissions on directories when deleting files.
From: Chad Joan <hidden>
Date: 2016-06-15 22:50:41
On Tue, Mar 1, 2011 at 2:44 PM, Jeff King [off-list ref] wrote:
On Tue, Mar 01, 2011 at 02:35:41PM -0500, Chad Joan wrote:quoted
Something fairly interesting: $ mkdir foo $ mkdir foo/bar $ ls -dl foo/bar drwxr-x--x 1 cjoan cjoan 0 Mar 1 14:31 foo/bar $ ls -dl foo drwxr-x--x 1 cjoan cjoan 0 Mar 1 14:31 foo $ echo "test" > foo/bar/baz.txt $ echo "somestuff" > foo/bar/somefile.txt $ ls -dl foo/bar drwxr-x--x 1 cjoan cjoan 0 Mar 1 14:31 foo/bar $ ls -dl foo drwxr-x--x 1 cjoan cjoan 0 Mar 1 14:31 foo $ rmdir foo/bar rmdir: failed to remove `foo/bar': Directory not empty $ ls -dl foo/bar drw------- 1 cjoan cjoan 0 Mar 1 14:32 foo/bar $ ls -dl foo drwxr-x--x 1 cjoan cjoan 0 Mar 1 14:31 foo The rmdir fails of course, but it also changes the permissions. So I take it that git always runs an rmdir on the parent directory when it removes a file? Seems like it would be a sensible way to do it on a system without this behavior.Exactly. Rather than spend time figuring out if the directory is removable (which would not be atomic, anyway), we just rmdir and ignore the error condition. I would argue that your filesystem is broken. Even if we implemented a workaround to opendir() and check for files, it would still have a race condition that could cause this situation to occur. -Peff
Ouch. Would it work to do something like alias rmdir to a script or program that would call /bin/rmdir and then fix up the permissions?