Re: Git changes permissions on directories when deleting files.

From: Jeff King <peff@peff.net>
Date: Mar 1, 2011, 19:44 UTC
Message-ID: <20110301194428.GD10082@sigill.intra.peff.net>
In-Reply-To: <AANLkTimBrUo_O6sjhSEf2sPKrYhjMcr24hwRe0kH4CgO@mail.gmail.com>

On Tue, Mar 01, 2011 at 02:35:41PM -0500, Chad Joan wrote:

Show 26 quoted lines

> 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