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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html