Re: Git changes permissions on directories when deleting files.

[Jeff King <peff@peff.net>]

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

> 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